Threat mitigation system and method

ABSTRACT

A computer-implemented method, computer program product and computing system for defining a universal detection rule for execution on a computing platform; processing the universal detection rule to generate a first detection rule that is executable on a first security-relevant subsystem within the computing platform; providing the first detection rule to the first security-relevant subsystem for execution on the first security-relevant subsystem; processing the universal detection rule to generate a second detection rule that is executable on a second security-relevant subsystem within the computing platform; and providing the second detection rule to the second security-relevant subsystem for execution on the first security-relevant subsystem.

RELATED APPLICATION(S)

This application claims the benefit of U.S. Provisional Application No. 63/326,375, filed on 1 Apr. 2022, the entire contents of which are herein incorporated by reference.

TECHNICAL FIELD

This disclosure relates to threat mitigation systems and, more particularly, to threat mitigation systems that utilize a universal query language.

BACKGROUND

In the computer world, there is a constant battle occurring between bad actors that want to attack computing platforms and good actors who try to prevent the same. Unfortunately, the complexity of such computer attacks in constantly increasing, so technology needs to be employed that understands the complexity of these attacks and is capable of addressing the same.

Threat mitigation systems may utilize and/or communicate with a plurality of security-relevant subsystems, wherein these security-relevant subsystems may gather information concerning such computer attacks. Unfortunately and in order to obtain such gathered information from these security-relevant subsystems, the user of the threat mitigation system would often be required to formulate a unique query for each security-relevant subsystem.

SUMMARY OF DISCLOSURE

Phase 4

In one implementation, a computer-implemented method is executed on a computing device and includes: defining a universal detection rule for execution on a computing platform; processing the universal detection rule to generate a first detection rule that is executable on a first security-relevant subsystem within the computing platform; providing the first detection rule to the first security-relevant subsystem for execution on the first security-relevant subsystem; processing the universal detection rule to generate a second detection rule that is executable on a second security-relevant subsystem within the computing platform; and providing the second detection rule to the second security-relevant subsystem for execution on the second security-relevant subsystem.

One or more of the following features may be included. A first plurality of detection events may be received from the first detection rule executed on the first security-relevant subsystem, wherein the first plurality of detection events concerns a plurality of security events occurring on the first security-relevant subsystem. Two or more associated detection events included within the first plurality of detection events may be identified; and the two or more associated detection events may be grouped to define a security incident. One or more artifacts/log entries may be associated with each of first plurality of detection events. Identifying two or more associated detection events included within the first plurality of detection events may include: identifying two or more detection events included within the first plurality of detection events that have common artifacts/log entries. Grouping the two or more associated detection events to define a security incident may include: grouping the one or more artifacts/log entries associated with each of the two or more associated detection events to form an artifact/log entry set for the security incident. A second plurality of detection events may be received from the second detection rule executed on the second security-relevant subsystem, wherein the second plurality of detection events concerns a plurality of security events occurring on the second security-relevant subsystem. Two or more associated detection events included within the second plurality of detection events may be identified; and the two or more associated detection events may be grouped to define a security incident. The one or more artifacts/log entries may be associated with each of second plurality of detection events. Identifying two or more associated detection events included within the second plurality of detection events may include: identifying two or more detection events included within the second plurality of detection events that have common artifacts/log entries. Grouping the two or more associated detection events to define a security incident may include: grouping the one or more artifacts/log entries associated with each of the two or more associated detection events to form an artifact/log entry set for the security incident. The first security-relevant subsystem and/or the second security-relevant subsystem may include one or more of: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems; Antivirus systems; operating systems; data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform.

In another implementation, a computer program product resides on a computer readable medium and has a plurality of instructions stored on it. When executed by a processor, the instructions cause the processor to perform operations including: defining a universal detection rule for execution on a computing platform; processing the universal detection rule to generate a first detection rule that is executable on a first security-relevant subsystem within the computing platform; providing the first detection rule to the first security-relevant subsystem for execution on the first security-relevant subsystem; processing the universal detection rule to generate a second detection rule that is executable on a second security-relevant subsystem within the computing platform; and providing the second detection rule to the second security-relevant subsystem for execution on the second security-relevant subsystem.

One or more of the following features may be included. A first plurality of detection events may be received from the first detection rule executed on the first security-relevant subsystem, wherein the first plurality of detection events concerns a plurality of security events occurring on the first security-relevant subsystem. Two or more associated detection events included within the first plurality of detection events may be identified; and the two or more associated detection events may be grouped to define a security incident. One or more artifacts/log entries may be associated with each of first plurality of detection events. Identifying two or more associated detection events included within the first plurality of detection events may include: identifying two or more detection events included within the first plurality of detection events that have common artifacts/log entries. Grouping the two or more associated detection events to define a security incident may include: grouping the one or more artifacts/log entries associated with each of the two or more associated detection events to form an artifact/log entry set for the security incident. A second plurality of detection events may be received from the second detection rule executed on the second security-relevant subsystem, wherein the second plurality of detection events concerns a plurality of security events occurring on the second security-relevant subsystem. Two or more associated detection events included within the second plurality of detection events may be identified; and the two or more associated detection events may be grouped to define a security incident. The one or more artifacts/log entries may be associated with each of second plurality of detection events. Identifying two or more associated detection events included within the second plurality of detection events may include: identifying two or more detection events included within the second plurality of detection events that have common artifacts/log entries. Grouping the two or more associated detection events to define a security incident may include: grouping the one or more artifacts/log entries associated with each of the two or more associated detection events to form an artifact/log entry set for the security incident. The first security-relevant subsystem and/or the second security-relevant subsystem may include one or more of: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems; Antivirus systems; operating systems; data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform.

In another implementation, a computing system includes a processor and a memory system configured to perform operations including: defining a universal detection rule for execution on a computing platform; processing the universal detection rule to generate a first detection rule that is executable on a first security-relevant subsystem within the computing platform; providing the first detection rule to the first security-relevant subsystem for execution on the first security-relevant subsystem; processing the universal detection rule to generate a second detection rule that is executable on a second security-relevant subsystem within the computing platform; and providing the second detection rule to the second security-relevant subsystem for execution on the second security-relevant subsystem.

One or more of the following features may be included. A first plurality of detection events may be received from the first detection rule executed on the first security-relevant subsystem, wherein the first plurality of detection events concerns a plurality of security events occurring on the first security-relevant subsystem. Two or more associated detection events included within the first plurality of detection events may be identified; and the two or more associated detection events may be grouped to define a security incident. One or more artifacts/log entries may be associated with each of first plurality of detection events. Identifying two or more associated detection events included within the first plurality of detection events may include: identifying two or more detection events included within the first plurality of detection events that have common artifacts/log entries. Grouping the two or more associated detection events to define a security incident may include: grouping the one or more artifacts/log entries associated with each of the two or more associated detection events to form an artifact/log entry set for the security incident. A second plurality of detection events may be received from the second detection rule executed on the second security-relevant subsystem, wherein the second plurality of detection events concerns a plurality of security events occurring on the second security-relevant subsystem. Two or more associated detection events included within the second plurality of detection events may be identified; and the two or more associated detection events may be grouped to define a security incident. The one or more artifacts/log entries may be associated with each of second plurality of detection events. Identifying two or more associated detection events included within the second plurality of detection events may include: identifying two or more detection events included within the second plurality of detection events that have common artifacts/log entries. Grouping the two or more associated detection events to define a security incident may include: grouping the one or more artifacts/log entries associated with each of the two or more associated detection events to form an artifact/log entry set for the security incident. The first security-relevant subsystem and/or the second security-relevant subsystem may include one or more of: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems; Antivirus systems; operating systems; data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform.

The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features and advantages will become apparent from the description, the drawings, and the claims

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagrammatic view of a distributed computing network including a computing device that executes a threat mitigation process according to an embodiment of the present disclosure;

FIG. 2 is a diagrammatic view of an exemplary probabilistic model rendered by a probabilistic process of the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIG. 3 is a diagrammatic view of the computing platform of FIG. 1 according to an embodiment of the present disclosure;

FIG. 4 is a flowchart of an implementation of the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIGS. 5-6 are diagrammatic views of screens rendered by the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIGS. 7-9 are flowcharts of other implementations of the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIG. 10 is a diagrammatic view of a screen rendered by the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIG. 11 is a flowchart of another implementation of the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIG. 12 is a diagrammatic view of a screen rendered by the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIG. 13 is a flowchart of another implementation of the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIG. 14 is a diagrammatic view of a screen rendered by the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIG. 15 is a flowchart of another implementation of the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIG. 16 is a diagrammatic view of screens rendered by the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIGS. 17-23 are flowcharts of other implementations of the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIG. 24 is a diagrammatic view of a screen rendered by the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIGS. 25-31 are flowcharts of other implementations of the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIG. 32 is a diagrammatic view of data field mapping according to an embodiment of the present disclosure;

FIG. 33 is a flowchart of another implementation of the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIG. 34 is a flowchart of another implementation of the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIG. 35 is a flowchart of another implementation of the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIG. 36 is a flowchart of another implementation of the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIG. 37 is a flowchart of another implementation of the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure;

FIG. 38 is a flowchart of another implementation of the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure; and

FIG. 39 is a flowchart of another implementation of the threat mitigation process of FIG. 1 according to an embodiment of the present disclosure.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

System Overview

Referring to FIG. 1 , there is shown threat mitigation process 10. Threat mitigation process 10 may be implemented as a server-side process, a client-side process, or a hybrid server-side/client-side process. For example, threat mitigation process 10 may be implemented as a purely server-side process via threat mitigation process 10 s. Alternatively, threat mitigation process 10 may be implemented as a purely client-side process via one or more of threat mitigation process 10 c 1, threat mitigation process 10 c 2, threat mitigation process 10 c 3, and threat mitigation process 10 c 4. Alternatively still, threat mitigation process 10 may be implemented as a hybrid server-side/client-side process via threat mitigation process 10 s in combination with one or more of threat mitigation process 10 c 1, threat mitigation process 10 c 2, threat mitigation process 10 c 3, and threat mitigation process 10 c 4. Accordingly, threat mitigation process 10 as used in this disclosure may include any combination of threat mitigation process 10 s, threat mitigation process 10 c 1, threat mitigation process 10 c 2, threat mitigation process, and threat mitigation process 10 c 4.

Threat mitigation process 10 s may be a server application and may reside on and may be executed by computing device 12, which may be connected to network 14 (e.g., the Internet or a local area network). Examples of computing device 12 may include, but are not limited to: a personal computer, a laptop computer, a personal digital assistant, a data-enabled cellular telephone, a notebook computer, a television with one or more processors embedded therein or coupled thereto, a cable/satellite receiver with one or more processors embedded therein or coupled thereto, a server computer, a series of server computers, a mini computer, a mainframe computer, or a cloud-based computing network.

The instruction sets and subroutines of threat mitigation process 10 s, which may be stored on storage device 16 coupled to computing device 12, may be executed by one or more processors (not shown) and one or more memory architectures (not shown) included within computing device 12. Examples of storage device 16 may include but are not limited to: a hard disk drive; a RAID device; a random-access memory (RAM); a read-only memory (ROM); and all forms of flash memory storage devices.

Network 14 may be connected to one or more secondary networks (e.g., network 18), examples of which may include but are not limited to: a local area network; a wide area network; or an intranet, for example.

Examples of threat mitigation processes 10 c 1, 10 c 2, 10 c 3, 10 c 4 may include but are not limited to a client application, a web browser, a game console user interface, or a specialized application (e.g., an application running on e.g., the Android™ platform or the iOS™ platform). The instruction sets and subroutines of threat mitigation processes 10 c 1, 10 c 2, 10 c 3, 10 c 4, which may be stored on storage devices 20, 22, 24, 26 (respectively) coupled to client electronic devices 28, 30, 32, 34 (respectively), may be executed by one or more processors (not shown) and one or more memory architectures (not shown) incorporated into client electronic devices 28, 30, 32, 34 (respectively). Examples of storage device 16 may include but are not limited to: a hard disk drive; a RAID device; a random-access memory (RAM); a read-only memory (ROM); and all forms of flash memory storage devices.

Examples of client electronic devices 28, 30, 32, 34 may include, but are not limited to, data-enabled, cellular telephone 28, laptop computer 30, personal digital assistant 32, personal computer 34, a notebook computer (not shown), a server computer (not shown), a gaming console (not shown), a smart television (not shown), and a dedicated network device (not shown). Client electronic devices 28, 30, 32, 34 may each execute an operating system, examples of which may include but are not limited to Microsoft Windows™, Android™, WebOS™, iOS®, Redhat Linux™, or a custom operating system.

Users 36, 38, 40, 42 may access threat mitigation process 10 directly through network 14 or through secondary network 18. Further, threat mitigation process 10 may be connected to network 14 through secondary network 18, as illustrated with link line 44.

The various client electronic devices (e.g., client electronic devices 28, 30, 32, 34) may be directly or indirectly coupled to network 14 (or network 18). For example, data-enabled, cellular telephone 28 and laptop computer 30 are shown wirelessly coupled to network 14 via wireless communication channels 46, 48 (respectively) established between data-enabled, cellular telephone 28, laptop computer 30 (respectively) and cellular network/bridge 50, which is shown directly coupled to network 14. Further, personal digital assistant 32 is shown wirelessly coupled to network 14 via wireless communication channel 52 established between personal digital assistant 32 and wireless access point (i.e., WAP) 54, which is shown directly coupled to network 14. Additionally, personal computer 34 is shown directly coupled to network 18 via a hardwired network connection.

WAP 54 may be, for example, an IEEE 802.11a, 802.11b, 802.11g, 802.11n, Wi-Fi, and/or Bluetooth device that is capable of establishing wireless communication channel 52 between personal digital assistant 32 and WAP 54. As is known in the art, IEEE 802.11x specifications may use Ethernet protocol and carrier sense multiple access with collision avoidance (i.e., CSMA/CA) for path sharing. The various 802.11x specifications may use phase-shift keying (i.e., PSK) modulation or complementary code keying (i.e., CCK) modulation, for example. As is known in the art, Bluetooth is a telecommunications industry specification that allows e.g., mobile phones, computers, and personal digital assistants to be interconnected using a short-range wireless connection.

Artificial Intelligence/Machines Learning Overview:

Assume for illustrative purposes that threat mitigation process 10 includes probabilistic process 56 (e.g., an artificial intelligence/machine learning process) that is configured to process information (e.g., information 58). As will be discussed below in greater detail, examples of information 58 may include but are not limited to platform information (e.g., structured or unstructured content) being scanned to detect security events (e.g., access auditing; anomalies; authentication; denial of services; exploitation; malware; phishing; spamming; reconnaissance; and/or web attack) within a monitored computing platform (e.g., computing platform 60).

As is known in the art, structured content may be content that is separated into independent portions (e.g., fields, columns, features) and, therefore, may have a pre-defined data model and/or is organized in a pre-defined manner. For example, if the structured content concerns an employee list: a first field, column or feature may define the first name of the employee; a second field, column or feature may define the last name of the employee; a third field, column or feature may define the home address of the employee; and a fourth field, column or feature may define the hire date of the employee.

Further and as is known in the art, unstructured content may be content that is not separated into independent portions (e.g., fields, columns, features) and, therefore, may not have a pre-defined data model and/or is not organized in a pre-defined manner. For example, if the unstructured content concerns the same employee list: the first name of the employee, the last name of the employee, the home address of the employee, and the hire date of the employee may all be combined into one field, column or feature.

For the following illustrative example, assume that information 58 is unstructured content, an example of which may include but is not limited to unstructured user feedback received by a company (e.g., text-based feedback such as text-messages, social media posts, and email messages; and transcribed voice-based feedback such as transcribed voice mail, and transcribed voice messages).

When processing information 58, probabilistic process 56 may use probabilistic modeling to accomplish such processing, wherein examples of such probabilistic modeling may include but are not limited to discriminative modeling, generative modeling, or combinations thereof.

As is known in the art, probabilistic modeling may be used within modern artificial intelligence systems (e.g., probabilistic process 56), in that these probabilistic models may provide artificial intelligence systems with the tools required to autonomously analyze vast quantities of data (e.g., information 58).

Examples of the tasks for which probabilistic modeling may be utilized may include but are not limited to:

-   -   predicting media (music, movies, books) that a user may like or         enjoy based upon media that the user has liked or enjoyed in the         past;     -   transcribing words spoken by a user into editable text;     -   grouping genes into gene clusters;     -   identifying recurring patterns within vast data sets;     -   filtering email that is believed to be spam from a user's inbox;     -   generating clean (i.e., non-noisy) data from a noisy data set;     -   analyzing (voice-based or text-based) customer feedback; and     -   diagnosing various medical conditions and diseases.

For each of the above-described applications of probabilistic modeling, an initial probabilistic model may be defined, wherein this initial probabilistic model may be subsequently (e.g., iteratively or continuously) modified and revised, thus allowing the probabilistic models and the artificial intelligence systems (e.g., probabilistic process 56) to “learn” so that future probabilistic models may be more precise and may explain more complex data sets.

Accordingly, probabilistic process 56 may define an initial probabilistic model for accomplishing a defined task (e.g., the analyzing of information 58). For the illustrative example, assume that this defined task is analyzing customer feedback (e.g., information 58) that is received from customers of e.g., store 62 via an automated feedback phone line. For this example, assume that information 58 is initially voice-based content that is processed via e.g., a speech-to-text process that results in unstructured text-based customer feedback (e.g., information 58).

With respect to probabilistic process 56, a probabilistic model may be utilized to go from initial observations about information 58 (e.g., as represented by the initial branches of a probabilistic model) to conclusions about information 58 (e.g., as represented by the leaves of a probabilistic model).

As used in this disclosure, the term “branch” may refer to the existence (or non-existence) of a component (e.g., a sub-model) of (or included within) a model. Examples of such a branch may include but are not limited to: an execution branch of a probabilistic program or other generative model, a part (or parts) of a probabilistic graphical model, and/or a component neural network that may (or may not) have been previously trained.

While the following discussion provides a detailed example of a probabilistic model, this is for illustrative purposes only and is not intended to be a limitation of this disclosure, as other configurations are possible and are considered to be within the scope of this disclosure. For example, the following discussion may concern any type of model (e.g., be it probabilistic or other) and, therefore, the below-described probabilistic model is merely intended to be one illustrative example of a type of model and is not intended to limit this disclosure to probabilistic models.

Additionally, while the following discussion concerns word-based routing of messages through a probabilistic model, this is for illustrative purposes only and is not intended to be a limitation of this disclosure, as other configurations are possible and are considered to be within the scope of this disclosure. Examples of other types of information that may be used to route messages through a probabilistic model may include: the order of the words within a message; and the punctuation interspersed throughout the message.

For example and referring also to FIG. 2 , there is shown one simplified example of a probabilistic model (e.g., probabilistic model 100) that may be utilized to analyze information 58 (e.g., unstructured text-based customer feedback) concerning store 62. The manner in which probabilistic model 100 may be automatically-generated by probabilistic process 56 will be discussed below in detail. In this particular example, probabilistic model 100 may receive information 58 (e.g., unstructured text-based customer feedback) at branching node 102 for processing. Assume that probabilistic model 100 includes four branches off of branching node 102, namely: service branch 104; selection branch 106; location branch 108; and value branch 110 that respectively lead to service node 112, selection node 114, location node 116, and value node 118.

As stated above, service branch 104 may lead to service node 112, which may be configured to process the portion of information 58 (e.g., unstructured text-based customer feedback) that concerns (in whole or in part) feedback concerning the customer service of store 62. For example, service node 112 may define service word list 120 that may include e.g., the word service, as well as synonyms of (and words related to) the word service (e.g., cashier, employee, greeter and manager). Accordingly and in the event that a portion of information 58 (e.g., a text-based customer feedback message) includes the word cashier, employee, greeter and/or manager, that portion of information 58 may be considered to be text-based customer feedback concerning the service received at store 62 and (therefore) may be routed to service node 112 of probabilistic model 100 for further processing. Assume for this illustrative example that probabilistic model 100 includes two branches off of service node 112, namely: good service branch 122 and bad service branch 124.

Good service branch 122 may lead to good service node 126, which may be configured to process the portion of information 58 (e.g., unstructured text-based customer feedback) that concerns (in whole or in part) good feedback concerning the customer service of store 62. For example, good service node 126 may define good service word list 128 that may include e.g., the word good, as well as synonyms of (and words related to) the word good (e.g., courteous, friendly, lovely, happy, and smiling). Accordingly and in the event that a portion of information 58 (e.g., a text-based customer feedback message) that was routed to service node 112 includes the word good, courteous, friendly, lovely, happy, and/or smiling, that portion of information 58 may be considered to be text-based customer feedback indicative of good service received at store 62 (and, therefore, may be routed to good service node 126).

Bad service branch 124 may lead to bad service node 130, which may be configured to process the portion of information 58 (e.g., unstructured text-based customer feedback) that concerns (in whole or in part) bad feedback concerning the customer service of store 62. For example, bad service node 130 may define bad service word list 132 that may include e.g., the word bad, as well as synonyms of (and words related to) the word bad (e.g., rude, mean, jerk, miserable, and scowling). Accordingly and in the event that a portion of information 58 (e.g., a text-based customer feedback message) that was routed to service node 112 includes the word bad, rude, mean, jerk, miserable, and/or scowling, that portion of information 58 may be considered to be text-based customer feedback indicative of bad service received at store 62 (and, therefore, may be routed to bad service node 130).

As stated above, selection branch 106 may lead to selection node 114, which may be configured to process the portion of information 58 (e.g., unstructured text-based customer feedback) that concerns (in whole or in part) feedback concerning the selection available at store 62. For example, selection node 114 may define selection word list 134 that may include e.g., words indicative of the selection available at store 62. Accordingly and in the event that a portion of information 58 (e.g., a text-based customer feedback message) includes any of the words defined within selection word list 134, that portion of information 58 may be considered to be text-based customer feedback concerning the selection available at store 62 and (therefore) may be routed to selection node 114 of probabilistic model 100 for further processing. Assume for this illustrative example that probabilistic model 100 includes two branches off of selection node 114, namely: good selection branch 136 and bad selection branch 138.

Good selection branch 136 may lead to good selection node 140, which may be configured to process the portion of information 58 (e.g., unstructured text-based customer feedback) that concerns (in whole or in part) good feedback concerning the selection available at store 62. For example, good selection node 140 may define good selection word list 142 that may include words indicative of a good selection at store 62. Accordingly and in the event that a portion of information 58 (e.g., a text-based customer feedback message) that was routed to selection node 114 includes any of the words defined within good selection word list 142, that portion of information 58 may be considered to be text-based customer feedback indicative of a good selection available at store 62 (and, therefore, may be routed to good selection node 140).

Bad selection branch 138 may lead to bad selection node 144, which may be configured to process the portion of information 58 (e.g., unstructured text-based customer feedback) that concerns (in whole or in part) bad feedback concerning the selection available at store 62. For example, bad selection node 144 may define bad selection word list 146 that may include words indicative of a bad selection at store 62. Accordingly and in the event that a portion of information 58 (e.g., a text-based customer feedback message) that was routed to selection node 114 includes any of the words defined within bad selection word list 146, that portion of information 58 may be considered to be text-based customer feedback indicative of a bad selection being available at store 62 (and, therefore, may be routed to bad selection node 144).

As stated above, location branch 108 may lead to location node 116, which may be configured to process the portion of information 58 (e.g., unstructured text-based customer feedback) that concerns (in whole or in part) feedback concerning the location of store 62. For example, location node 116 may define location word list 148 that may include e.g., words indicative of the location of store 62. Accordingly and in the event that a portion of information 58 (e.g., a text-based customer feedback message) includes any of the words defined within location word list 148, that portion of information 58 may be considered to be text-based customer feedback concerning the location of store 62 and (therefore) may be routed to location node 116 of probabilistic model 100 for further processing. Assume for this illustrative example that probabilistic model 100 includes two branches off of location node 116, namely: good location branch 150 and bad location branch 152.

Good location branch 150 may lead to good location node 154, which may be configured to process the portion of information 58 (e.g., unstructured text-based customer feedback) that concerns (in whole or in part) good feedback concerning the location of store 62. For example, good location node 154 may define good location word list 156 that may include words indicative of store 62 being in a good location. Accordingly and in the event that a portion of information 58 (e.g., a text-based customer feedback message) that was routed to location node 116 includes any of the words defined within good location word list 156, that portion of information 58 may be considered to be text-based customer feedback indicative of store 62 being in a good location (and, therefore, may be routed to good location node 154).

Bad location branch 152 may lead to bad location node 158, which may be configured to process the portion of information 58 (e.g., unstructured text-based customer feedback) that concerns (in whole or in part) bad feedback concerning the location of store 62. For example, bad location node 158 may define bad location word list 160 that may include words indicative of store 62 being in a bad location. Accordingly and in the event that a portion of information 58 (e.g., a text-based customer feedback message) that was routed to location node 116 includes any of the words defined within bad location word list 160, that portion of information 58 may be considered to be text-based customer feedback indicative of store 62 being in a bad location (and, therefore, may be routed to bad location node 158).

As stated above, value branch 110 may lead to value node 118, which may be configured to process the portion of information 58 (e.g., unstructured text-based customer feedback) that concerns (in whole or in part) feedback concerning the value received at store 62. For example, value node 118 may define value word list 162 that may include e.g., words indicative of the value received at store 62. Accordingly and in the event that a portion of information 58 (e.g., a text-based customer feedback message) includes any of the words defined within value word list 162, that portion of information 58 may be considered to be text-based customer feedback concerning the value received at store 62 and (therefore) may be routed to value node 118 of probabilistic model 100 for further processing. Assume for this illustrative example that probabilistic model 100 includes two branches off of value node 118, namely: good value branch 164 and bad value branch 166.

Good value branch 164 may lead to good value node 168, which may be configured to process the portion of information 58 (e.g., unstructured text-based customer feedback) that concerns (in whole or in part) good value being received at store 62. For example, good value node 168 may define good value word list 170 that may include words indicative of receiving good value at store 62. Accordingly and in the event that a portion of information 58 (e.g., a text-based customer feedback message) that was routed to value node 118 includes any of the words defined within good value word list 170, that portion of information 58 may be considered to be text-based customer feedback indicative of good value being received at store 62 (and, therefore, may be routed to good value node 168).

Bad value branch 166 may lead to bad value node 172, which may be configured to process the portion of information 58 (e.g., unstructured text-based customer feedback) that concerns (in whole or in part) bad value being received at store 62. For example, bad value node 172 may define bad value word list 174 that may include words indicative of receiving bad value at store 62. Accordingly and in the event that a portion of information 58 (e.g., a text-based customer feedback message) that was routed to value node 118 includes any of the words defined within bad value word list 174, that portion of information 58 may be considered to be text-based customer feedback indicative of bad value being received at store 62 (and, therefore, may be routed to bad value node 172).

Once it is established that good or bad customer feedback was received concerning store 62 (i.e., with respect to the service, the selection, the location or the value), representatives and/or agents of store 62 may address the provider of such good or bad feedback via e.g., social media postings, text-messages and/or personal contact.

Assume for illustrative purposes that user 36 uses data-enabled, cellular telephone 28 to provide feedback 64 (e.g., a portion of information 58) to an automated feedback phone line concerning store 62. Upon receiving feedback 64 for analysis, probabilistic process 56 may identify any pertinent content that is included within feedback 64.

For illustrative purposes, assume that user 36 was not happy with their experience at store 62 and that feedback 64 provided by user 36 was “my cashier was rude and the weather was rainy”. Accordingly and for this example, probabilistic process 56 may identify the pertinent content (included within feedback 64) as the phrase “my cashier was rude” and may ignore/remove the irrelevant content “the weather was rainy”. As (in this example) feedback 64 includes the word “cashier”, probabilistic process 56 may route feedback 64 to service node 112 via service branch 104. Further, as feedback 64 also includes the word “rude”, probabilistic process 56 may route feedback 64 to bad service node 130 via bad service branch 124 and may consider feedback 64 to be text-based customer feedback indicative of bad service being received at store 62.

For further illustrative purposes, assume that user 36 was happy with their experience at store 62 and that feedback 64 provided by user 36 was “the clothing I purchased was classy but my cab got stuck in traffic”. Accordingly and for this example, probabilistic process 56 may identify the pertinent content (included within feedback 64) as the phrase “the clothing I purchased was classy” and may ignore/remove the irrelevant content “my cab got stuck in traffic”. As (in this example) feedback 64 includes the word “clothing”, probabilistic process 56 may route feedback 64 to selection node 114 via selection branch 106. Further, as feedback 64 also includes the word “classy”, probabilistic process 56 may route feedback 64 to good selection node 140 via good selection branch 136 and may consider feedback 64 to be text-based customer feedback indicative of a good selection being available at store 62.

Model Generation Overview:

While the following discussion concerns the automated generation of a probabilistic model, this is for illustrative purposes only and is not intended to be a limitation of this disclosure, as other configurations are possible and are considered to be within the scope of this disclosure. For example, the following discussion of automated generation may be utilized on any type of model. For example, the following discussion may be applicable to any other form of probabilistic model or any form of generic model (such as Dempster Shaffer theory or fuzzy logic).

As discussed above, probabilistic model 100 may be utilized to categorize information 58, thus allowing the various messages included within information 58 to be routed to (in this simplified example) one of eight nodes (e.g., good service node 126, bad service node 130, good selection node 140, bad selection node 144, good location node 154, bad location node 158, good value node 168, and bad value node 172). For the following example, assume that store 62 is a long-standing and well-established shopping establishment. Further, assume that information 58 is a very large quantity of voice mail messages (>10,000 messages) that were left by customers of store 62 on a voice-based customer feedback line. Additionally, assume that this very large quantity of voice mail messages (>10,000) have been transcribed into a very large quantity of text-based messages (>10,000).

Probabilistic process 56 may be configured to automatically define probabilistic model 100 based upon information 58. Accordingly, probabilistic process 56 may receive content (e.g., a very large quantity of text-based messages) and may be configured to define one or more probabilistic model variables for probabilistic model 100. For example, probabilistic process 56 may be configured to allow a user to specify such probabilistic model variables. Another example of such variables may include but is not limited to values and/or ranges of values for a data flow variable. For the following discussion and for this disclosure, examples of a “variable” may include but are not limited to variables, parameters, ranges, branches and nodes.

Specifically and for this example, assume that probabilistic process 56 defines the initial number of branches (i.e., the number of branches off of branching node 102) within probabilistic model 100 as four (i.e., service branch 104, selection branch 106, location branch 108 and value branch 110). The defining of the initial number of branches (i.e., the number of branches off of branching node 102) within probabilistic model 100 as four may be effectuated in various ways (e.g., manually or algorithmically). Further and when defining probabilistic model 100 based, at least in part, upon information 58 and the one or more model variables (i.e., defining the number of branches off of branching node 102 as four), probabilistic process 56 may process information 58 to identify the pertinent content included within information 58. As discussed above, probabilistic process 56 may identify the pertinent content (included within information 58) and may ignore/remove the irrelevant content.

This type of processing of information 58 may continue for all of the very large quantity of text-based messages (>10,000) included within information 58. And using the probabilistic modeling technique described above, probabilistic process 56 may define a first version of the probabilistic model (e.g., probabilistic model 100) based, at least in part, upon pertinent content found within information 58. Accordingly, a first text-based message included within information 58 may be processed to extract pertinent information from that first message, wherein this pertinent information may be grouped in a manner to correspond (at least temporarily) with the requirement that four branches originate from branching node 102 (as defined above).

As probabilistic process 56 continues to process information 58 to identify pertinent content included within information 58, probabilistic process 56 may identify patterns within these text-based message included within information 58. For example, the messages may all concern one or more of the service, the selection, the location and/or the value of store 62. Further and e.g., using the probabilistic modeling technique described above, probabilistic process 56 may process information 58 to e.g.: a) sort text-based messages concerning the service into positive or negative service messages; b) sort text-based messages concerning the selection into positive or negative selection messages; c) sort text-based messages concerning the location into positive or negative location messages; and/or d) sort text-based messages concerning the value into positive or negative service messages. For example, probabilistic process 56 may define various lists (e.g., lists 128, 132, 142, 146, 156, 160, 170, 174) by starting with a root word (e.g., good or bad) and may then determine synonyms for these words and use those words and synonyms to populate lists 128, 132, 142, 146, 156, 160, 170, 174.

Continuing with the above-stated example, once information 58 (or a portion thereof) is processed by probabilistic process 56, probabilistic process 56 may define a first version of the probabilistic model (e.g., probabilistic model 100) based, at least in part, upon pertinent content found within information 58. Probabilistic process 56 may compare the first version of the probabilistic model (e.g., probabilistic model 100) to information 58 to determine if the first version of the probabilistic model (e.g., probabilistic model 100) is a good explanation of the content.

When determining if the first version of the probabilistic model (e.g., probabilistic model 100) is a good explanation of the content, probabilistic process 56 may use an ML algorithm to fit the first version of the probabilistic model (e.g., probabilistic model 100) to the content, wherein examples of such an ML algorithm may include but are not limited to one or more of: an inferencing algorithm, a learning algorithm, an optimization algorithm, and a statistical algorithm.

For example and as is known in the art, probabilistic model 100 may be used to generate messages (in addition to analyzing them). For example and when defining a first version of the probabilistic model (e.g., probabilistic model 100) based, at least in part, upon pertinent content found within information 58, probabilistic process 56 may define a weight for each branch within probabilistic model 100 based upon information 58. For example, threat mitigation process 10 may equally weight each of branches 104, 106, 108, 110 at 25%. Alternatively, if e.g., a larger percentage of information 58 concerned the service received at store 62, threat mitigation process 10 may equally weight each of branches 106, 108, 110 at 20%, while more heavily weighting branch 104 at 40%.

Accordingly and when probabilistic process 56 compares the first version of the probabilistic model (e.g., probabilistic model 100) to information 58 to determine if the first version of the probabilistic model (e.g., probabilistic model 100) is a good explanation of the content, probabilistic process 56 may generate a very large quantity of messages e.g., by auto-generating messages using the above-described probabilities, the above-described nodes & node types, and the words defined in the above-described lists (e.g., lists 128, 132, 142, 146, 156, 160, 170, 174), thus resulting in generated information 58′. Generated information 58′ may then be compared to information 58 to determine if the first version of the probabilistic model (e.g., probabilistic model 100) is a good explanation of the content. For example, if generated information 58′ exceeds a threshold level of similarity to information 58, the first version of the probabilistic model (e.g., probabilistic model 100) may be deemed a good explanation of the content. Conversely, if generated information 58′ does not exceed a threshold level of similarity to information 58, the first version of the probabilistic model (e.g., probabilistic model 100) may be deemed not a good explanation of the content.

If the first version of the probabilistic model (e.g., probabilistic model 100) is not a good explanation of the content, probabilistic process 56 may define a revised version of the probabilistic model (e.g., revised probabilistic model 100′). When defining revised probabilistic model 100′, probabilistic process 56 may e.g., adjust weighting, adjust probabilities, adjust node counts, adjust node types, and/or adjust branch counts to define the revised version of the probabilistic model (e.g., revised probabilistic model 100′). Once defined, the above-described process of auto-generating messages (this time using revised probabilistic model 100′) may be repeated and this newly-generated content (e.g., generated information 58″) may be compared to information 58 to determine if e.g., revised probabilistic model 100′ is a good explanation of the content. If revised probabilistic model 100′ is not a good explanation of the content, the above-described process may be repeated until a proper probabilistic model is defined.

The Threat Mitigation Process

As discussed above, threat mitigation process 10 may include probabilistic process 56 (e.g., an artificial intelligence/machine learning process) that may be configured to process information (e.g., information 58), wherein examples of information 58 may include but are not limited to platform information (e.g., structured or unstructured content) that may be scanned to detect security events (e.g., access auditing; anomalies; authentication; denial of services; exploitation; malware; phishing; spamming; reconnaissance; and/or web attack) within a monitored computing platform (e.g., computing platform 60).

Referring also to FIG. 3 , the monitored computing platform (e.g., computing platform 60) utilized by business today may be a highly complex, multi-location computing system/network that may span multiple buildings/locations/countries. For this illustrative example, the monitored computing platform (e.g., computing platform 60) is shown to include many discrete computing devices, examples of which may include but are not limited to: server computers (e.g., server computers 200, 202), desktop computers (e.g., desktop computer 204), and laptop computers (e.g., laptop computer 206), all of which may be coupled together via a network (e.g., network 208), such as an Ethernet network. Computing platform 60 may be coupled to an external network (e.g., Internet 210) through WAF (i.e., Web Application Firewall) 212. A wireless access point (e.g., WAP 214) may be configured to allow wireless devices (e.g., smartphone 216) to access computing platform 60. Computing platform 60 may include various connectivity devices that enable the coupling of devices within computing platform 60, examples of which may include but are not limited to: switch 216, router 218 and gateway 220. Computing platform 60 may also include various storage devices (e.g., NAS 222), as well as functionality (e.g., API Gateway 224) that allows software applications to gain access to one or more resources within computing platform 60.

In addition to the devices and functionality discussed above, other technology (e.g., security-relevant subsystems 226) may be deployed within computing platform 60 to monitor the operation of (and the activity within) computing platform 60. Examples of security-relevant subsystems 226 may include but are not limited to: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, antivirus systems, operating systems, data lakes; data logs, security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform.

Each of security-relevant subsystems 226 may monitor and log their activity with respect to computing platform 60, resulting in the generation of platform information 228. For example, platform information 228 associated with a client-defined MDM (i.e., Mobile Device Management) system may monitor and log the mobile devices that were allowed access to computing platform 60.

Further, SEIM (i.e., Security Information and Event Management) system 230 may be deployed within computing platform 60. As is known in the art, SIEM system 230 is an approach to security management that combines SIM (security information management) functionality and SEM (security event management) functionality into one security management system. The underlying principles of a SIEM system is to aggregate relevant data from multiple sources, identify deviations from the norm and take appropriate action. For example, when a security event is detected, SIEM system 230 might log additional information, generate an alert and instruct other security controls to mitigate the security event. Accordingly, SIEM system 230 may be configured to monitor and log the activity of security-relevant subsystems 226 (e.g., CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, antivirus systems, operating systems, data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform).

Computing Platform Analysis & Reporting

As will be discussed below in greater detail, threat mitigation process 10 may be configured to e.g., analyze computing platform 60 and provide reports to third-parties concerning the same. Further and since security-relevant subsystems 226 may monitor and log activity with respect to computing platform 60 and computing platform 60 may include a wide range of computing devices (e.g., server computers 200, 202, desktop computer 204, laptop computer 206, network 208, web application firewall 212, wireless access point 214, switch 216, router 218, gateway 220, NAS 222, and API Gateway 224), threat mitigation process 10 may provide holistic monitoring of the entirety of computing platform 60 (e.g., both central devices and end point devices), generally referred to as XDR (extended detection and response) functionality. As defined by analyst firm Gartner, Extended Detection and Response (XDR) is “a SaaS-based, vendor-specific, security threat detection and incident response tool that natively integrates multiple security products into a cohesive security operations system that unifies all licensed components.”

Referring also to FIGS. 4-6 , threat mitigation process 10 may be configured to obtain and combine information from multiple security-relevant subsystem to generate a security profile for computing platform 60. For example, threat mitigation process 10 may obtain 300 first system-defined platform information (e.g., system-defined platform information 232) concerning a first security-relevant subsystem (e.g., the number of operating systems deployed) within computing platform 60 and may obtain 302 at least a second system-defined platform information (e.g., system-defined platform information 234) concerning at least a second security-relevant subsystem (e.g., the number of antivirus systems deployed) within computing platform 60.

The first system-defined platform information (e.g., system-defined platform information 232) and the at least a second system-defined platform information (e.g., system-defined platform information 234) may be obtained from one or more log files defined for computing platform 60.

Specifically, system-defined platform information 232 and/or system-defined platform information 234 may be obtained from SIEM system 230, wherein (and as discussed above) SIEM system 230 may be configured to monitor and log the activity of security-relevant subsystems 226 (e.g., CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, antivirus systems, operating systems, data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform).

Alternatively, the first system-defined platform information (e.g., system-defined platform information 232) and the at least a second system-defined platform information (e.g., system-defined platform information 234) may be obtained from the first security-relevant subsystem (e.g., the operating systems themselves) and the at least a second security-relevant subsystem (e.g., the antivirus systems themselves). Specifically, system-defined platform information 232 and/or system-defined platform information 234 may be obtained directly from the security-relevant subsystems (e.g., the operating systems and/or the antivirus systems), which (as discussed above) may be configured to self-document their activity.

Threat mitigation process 10 may combine 308 the first system-defined platform information (e.g., system-defined platform information 232) and the at least a second system-defined platform information (e.g., system-defined platform information 234) to form system-defined consolidated platform information 236. Accordingly and in this example, system-defined consolidated platform information 236 may independently define the security-relevant subsystems (e.g., security-relevant subsystems 226) present on computing platform 60.

Threat mitigation process 10 may generate 310 a security profile (e.g., security profile 350) based, at least in part, upon system-defined consolidated platform information 236. Through the use of security profile (e.g., security profile 350), the user/owner/operator of computing platform 60 may be able to see that e.g., they have a security score of 605 out of a possible score of 1,000, wherein the average customer has a security score of 237. While security profile 350 in shown in the example to include several indicators that may enable a user to compare (in this example) computing platform 60 to other computing platforms, this is for illustrative purposes only and is not intended to be a limitation of this disclosure, as it is understood that other configurations are possible and are considered to be within the scope of this disclosure.

Naturally, the format, appearance and content of security profile 350 may be varied greatly depending upon the design criteria and anticipated performance/use of threat mitigation process 10. Accordingly, the appearance, format, completeness and content of security profile 350 is for illustrative purposes only and is not intended to be a limitation of this disclosure, as other configurations are possible and are considered to be within the scope of this disclosure. For example, content may be added to security profile 350, removed from security profile 350, and/or reformatted within security profile 350.

Additionally, threat mitigation process 10 may obtain 312 client-defined consolidated platform information 238 for computing platform 60 from a client information source, examples of which may include but are not limited to one or more client-completed questionnaires (e.g., questionnaires 240) and/or one or more client-deployed platform monitors (e.g., client-deployed platform monitor 242, which may be configured to effectuate SIEM functionality). Accordingly and in this example, client-defined consolidated platform information 238 may define the security-relevant subsystems (e.g., security-relevant subsystems 226) that the client believes are present on computing platform 60.

When generating 310 a security profile (e.g., security profile 350) based, at least in part, upon system-defined consolidated platform information 236, threat mitigation process 10 may compare 314 the system-defined consolidated platform information (e.g., system-defined consolidated platform information 236) to the client-defined consolidated platform information (e.g., client-defined consolidated platform information 238) to define differential consolidated platform information 352 for computing platform 60.

Differential consolidated platform information 352 may include comparison table 354 that e.g., compares computing platform 60 to other computing platforms. For example and in this particular implementation of differential consolidated platform information 352, comparison table 354 is shown to include three columns, namely: security-relevant subsystem column 356 (that identifies the security-relevant subsystems in question); system-defined consolidated platform information column 358 (that is based upon system-defined consolidated platform information 236 and independently defines what security-relevant subsystems are present on computing platform 60); and client-defined consolidated platform column 360 (that is based upon client-defined platform information 238 and defines what security-relevant subsystems the client believes are present on computing platform 60). As shown within comparison table 354, there are considerable differences between that is actually present on computing platform 60 and what is believed to be present on computing platform 60 (e.g., 1 IAM system vs. 10 IAM systems; 4,000 operating systems vs. 10,000 operating systems, 6 DNS systems vs. 10 DNS systems; 0 antivirus systems vs. 1 antivirus system, and 90 firewalls vs. 150 firewalls).

Naturally, the format, appearance and content of differential consolidated platform information 352 may be varied greatly depending upon the design criteria and anticipated performance/use of threat mitigation process 10. Accordingly, the appearance, format, completeness and content of differential consolidated platform information 352 is for illustrative purposes only and is not intended to be a limitation of this disclosure, as other configurations are possible and are considered to be within the scope of this disclosure. For example, content may be added to differential consolidated platform information 352, removed from differential consolidated platform information 352, and/or reformatted within differential consolidated platform information 352.

Referring also to FIG. 7 , threat mitigation process 10 may be configured to compare what security relevant subsystems are actually included within computing platform 60 versus what security relevant subsystems were believed to be included within computing platform 60. As discussed above, threat mitigation process 10 may combine 308 the first system-defined platform information (e.g., system-defined platform information 232) and the at least a second system-defined platform information (e.g., system-defined platform information 234) to form system-defined consolidated platform information 236.

Threat mitigation process 10 may obtain 400 system-defined consolidated platform information 236 for computing platform 60 from an independent information source, examples of which may include but are not limited to: one or more log files defined for computing platform 60 (e.g., such as those maintained by SIEM system 230); and two or more security-relevant subsystems (e.g., directly from the operating system security-relevant subsystem and the antivirus security-relevant subsystem) deployed within computing platform 60.

Further and as discussed above, threat mitigation process 10 may obtain 312 client-defined consolidated platform information 238 for computing platform 60 from a client information source, examples of which may include but are not limited to one or more client-completed questionnaires (e.g., questionnaires 240) and/or one or more client-deployed platform monitors (e.g., client-deployed platform monitor 242, which may be configured to effectuate SIEM functionality).

Additionally and as discussed above, threat mitigation process 10 may compare 402 system-defined consolidated platform information 236 to client-defined consolidated platform information 238 to define differential consolidated platform information 352 for computing platform 60, wherein differential consolidated platform information 352 may include comparison table 354 that e.g., compares computing platform 60 to other computing platforms.

Threat mitigation process 10 may process 404 system-defined consolidated platform information 236 prior to comparing 402 system-defined consolidated platform information 236 to client-defined consolidated platform information 238 to define differential consolidated platform information 352 for computing platform 60. Specifically, threat mitigation process 10 may process 404 system-defined consolidated platform information 236 so that it is comparable to client-defined consolidated platform information 238.

For example and when processing 404 system-defined consolidated platform information 236, threat mitigation process 10 may homogenize 406 system-defined consolidated platform information 236 prior to comparing 402 system-defined consolidated platform information 236 to client-defined consolidated platform information 238 to define differential consolidated platform information 352 for computing platform 60. Such homogenization 406 may result in system-defined consolidated platform information 236 and client-defined consolidated platform information 238 being comparable to each other (e.g., to accommodate for differing data nomenclatures/headers).

Further and when processing 404 system-defined consolidated platform information 236, threat mitigation process 10 may normalize 408 system-defined consolidated platform information 236 prior to comparing 402 system-defined consolidated platform information 236 to client-defined consolidated platform information 238 to define differential consolidated platform information 352 for computing platform 60 (e.g., to accommodate for data differing scales/ranges).

Referring also to FIG. 8 , threat mitigation process 10 may be configured to compare what security relevant subsystems are actually included within computing platform 60 versus what security relevant subsystems were believed to be included within computing platform 60.

As discussed above, threat mitigation process 10 may obtain 400 system-defined consolidated platform information 236 for computing platform 60 from an independent information source, examples of which may include but are not limited to: one or more log files defined for computing platform 60 (e.g., such as those maintained by SIEM system 230); and two or more security-relevant subsystems (e.g., directly from the operating system security-relevant subsystem and the antivirus security-relevant subsystem) deployed within computing platform 60

Further and as discussed above, threat mitigation process 10 may obtain 312 client-defined consolidated platform information 238 for computing platform 60 from a client information source, examples of which may include but are not limited to one or more client-completed questionnaires (e.g., questionnaires 240) and/or one or more client-deployed platform monitors (e.g., client-deployed platform monitor 242, which may be configured to effectuate SIEM functionality).

Threat mitigation process 10 may present 450 differential consolidated platform information 352 for computing platform 60 to a third-party, examples of which may include but are not limited to the user/owner/operator of computing platform 60.

Additionally and as discussed above, threat mitigation process 10 may compare 402 system-defined consolidated platform information 236 to client-defined consolidated platform information 238 to define differential consolidated platform information 352 for computing platform 60, wherein differential consolidated platform information 352 may include comparison table 354 that e.g., compares computing platform 60 to other computing platforms, wherein (and as discussed above) threat mitigation process 10 may process 404 (e.g., via homogenizing 406 and/or normalizing 408) system-defined consolidated platform information 236 prior to comparing 402 system-defined consolidated platform information 236 to client-defined consolidated platform information 236 to define differential consolidated platform information 352 for computing platform 60.

Computing Platform Analysis & Recommendation

As will be discussed below in greater detail, threat mitigation process 10 may be configured to e.g., analyze & display the vulnerabilities of computing platform 60.

Referring also to FIG. 9 , threat mitigation process 10 may be configured to make recommendations concerning security relevant subsystems that are missing from computing platform 60. As discussed above, threat mitigation process 10 may obtain 500 consolidated platform information for computing platform 60 to identify one or more deployed security-relevant subsystems 226 (e.g., CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, antivirus systems, operating systems, data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform). This consolidated platform information may be obtained from an independent information source (e.g., such as SIEM system 230 that may provide system-defined consolidated platform information 236) and/or may be obtained from a client information source (e.g., such as questionnaires 240 that may provide client-defined consolidated platform information 238).

Referring also to FIG. 10 , threat mitigation process 10 may process 506 the consolidated platform information (e.g., system-defined consolidated platform information 236 and/or client-defined consolidated platform information 238) to identify one or more non-deployed security-relevant subsystems (within computing platform 60) and may then generate 508 a list of ranked & recommended security-relevant subsystems (e.g., non-deployed security-relevant subsystem list 550) that ranks the one or more non-deployed security-relevant subsystems.

For this particular illustrative example, non-deployed security-relevant subsystem list 550 is shown to include column 552 that identifies six non-deployed security-relevant subsystems, namely: a CDN subsystem, a WAF subsystem, a DAM subsystem; a UBA subsystem; an API subsystem, and an MDM subsystem.

When generating 508 a list of ranked & recommended security-relevant subsystems (e.g., non-deployed security-relevant subsystem list 550) that ranks the one or more non-deployed security-relevant subsystems, threat mitigation process 10 may rank 510 the one or more non-deployed security-relevant subsystems (e.g., a CDN subsystem, a WAF subsystem, a DAM subsystem; a UBA subsystem; a API subsystem, and an MDM subsystem) based upon the anticipated use of the one or more non-deployed security-relevant subsystems within computing platform 60. This ranking 510 of the non-deployed security-relevant subsystems (e.g., a CDN subsystem, a WAF subsystem, a DAM subsystem; a UBA subsystem; a API subsystem, and an MDM subsystem) may be agnostic in nature and may be based on the functionality/effectiveness of the non-deployed security-relevant subsystems and the anticipated manner in which their implementation may impact the functionality/security of computing platform 60.

Threat mitigation process 10 may provide 512 the list of ranked & recommended security-relevant subsystems (e.g., non-deployed security-relevant subsystem list 550) to a third-party, examples of which may include but are not limited to a user/owner/operator of computing platform 60.

Additionally, threat mitigation process 10 may identify 514 a comparative for at least one of the non-deployed security-relevant subsystems (e.g., a CDN subsystem, a WAF subsystem, a DAM subsystem; a UBA subsystem; an API subsystem, and an MDM subsystem) defined within the list of ranked & recommended security-relevant subsystems (e.g., non-deployed security-relevant subsystem list 550). This comparative may include vendor customers in a specific industry comparative and/or vendor customers in any industry comparative.

For example and in addition to column 552, non-deployed security-relevant subsystem list 550 may include columns 554, 556 for defining the comparatives for the six non-deployed security-relevant subsystems, namely: a CDN subsystem, a WAF subsystem, a DAM subsystem; a UBA subsystem; an API subsystem, and an MDM subsystem. Specifically, column 554 is shown to define comparatives concerning vendor customers that own the non-deployed security-relevant subsystems in a specific industry (i.e., the same industry as the user/owner/operator of computing platform 60). Additionally, column 556 is shown to define comparatives concerning vendor customers that own the non-deployed security-relevant subsystems in any industry (i.e., not necessarily the same industry as the user/owner/operator of computing platform 60). For example and concerning the comparatives of the WAF subsystem: 33% of the vendor customers in the same industry as the user/owner/operator of computing platform 60 deploy a WAF subsystem; while 71% of the vendor customers in any industry deploy a WAF subsystem.

Naturally, the format, appearance and content of non-deployed security-relevant subsystem list 550 may be varied greatly depending upon the design criteria and anticipated performance/use of threat mitigation process 10. Accordingly, the appearance, format, completeness and content of non-deployed security-relevant subsystem list 550 is for illustrative purposes only and is not intended to be a limitation of this disclosure, as other configurations are possible and are considered to be within the scope of this disclosure. For example, content may be added to non-deployed security-relevant subsystem list 550, removed from non-deployed security-relevant subsystem list 550, and/or reformatted within non-deployed security-relevant subsystem list 550.

Referring also to FIG. 11 , threat mitigation process 10 may be configured to compare the current capabilities to the possible capabilities of computing platform 60. As discussed above, threat mitigation process 10 may obtain 600 consolidated platform information to identify current security-relevant capabilities for computing platform 60. This consolidated platform information may be obtained from an independent information source (e.g., such as SIEM system 230 that may provide system-defined consolidated platform information 236) and/or may be obtained from a client information source (e.g., such as questionnaires 240 that may provide client-defined consolidated platform information 238. Threat mitigation process 10 may then determine 606 possible security-relevant capabilities for computing platform 60 (i.e., the difference between the current security-relevant capabilities of computing platform 60 and the possible security-relevant capabilities of computing platform 60. For example, the possible security-relevant capabilities may concern the possible security-relevant capabilities of computing platform 60 using the currently-deployed security-relevant subsystems. Additionally/alternatively, the possible security-relevant capabilities may concern the possible security-relevant capabilities of computing platform 60 using one or more supplemental security-relevant subsystems.

Referring also to FIG. 12 and as will be explained below, threat mitigation process 10 may generate 608 comparison information 650 that compares the current security-relevant capabilities of computing platform 60 to the possible security-relevant capabilities of computing platform 60 to identify security-relevant deficiencies. Comparison information 650 may include graphical comparison information, such as multi-axial graphical comparison information that simultaneously illustrates a plurality of security-relevant deficiencies.

For example, comparison information 650 may define (in this particular illustrative example) graphical comparison information that include five axes (e.g. axes 652, 654, 656, 658, 660) that correspond to five particular types of computer threats. Comparison information 650 includes origin 662, the point at which computing platform 60 has no protection with respect to any of the five types of computer threats that correspond to axes 652, 654, 656, 658, 660. Accordingly, as the capabilities of computing platform 60 are increased to counter a particular type of computer threat, the data point along the corresponding axis is proportionately displaced from origin 652.

As discussed above, threat mitigation process 10 may obtain 600 consolidated platform information to identify current security-relevant capabilities for computing platform 60. Concerning such current security-relevant capabilities for computing platform 60, these current security-relevant capabilities are defined by data points 664, 666, 668, 670, 672, the combination of which define bounded area 674. Bounded area 674 (in this example) defines the current security-relevant capabilities of computing platform 60.

Further and as discussed above, threat mitigation process 10 may determine 606 possible security-relevant capabilities for computing platform 60 (i.e., the difference between the current security-relevant capabilities of computing platform 60 and the possible security-relevant capabilities of computing platform 60.

As discussed above, the possible security-relevant capabilities may concern the possible security-relevant capabilities of computing platform 60 using the currently-deployed security-relevant subsystems. For example, assume that the currently-deployed security relevant subsystems are not currently being utilized to their full potential. Accordingly, certain currently-deployed security relevant subsystems may have certain features that are available but are not utilized and/or disabled. Further, certain currently-deployed security relevant subsystems may have expanded features available if additional licensing fees are paid. Therefore and concerning such possible security-relevant capabilities of computing platform 60 using the currently-deployed security-relevant subsystems, data points 676, 678, 680, 682, 684 may define bounded area 686 (which represents the full capabilities of the currently-deployed security-relevant subsystems within computing platform 60).

Further and as discussed above, the possible security-relevant capabilities may concern the possible security-relevant capabilities of computing platform 60 using one or more supplemental security-relevant subsystems. For example, assume that supplemental security-relevant subsystems are available for the deployment within computing platform 60. Therefore and concerning such possible security-relevant capabilities of computing platform 60 using such supplemental security-relevant subsystems, data points 688, 690, 692, 694, 696 may define bounded area 698 (which represents the total capabilities of computing platform 60 when utilizing the full capabilities of the currently-deployed security-relevant subsystems and any supplemental security-relevant subsystems).

Naturally, the format, appearance and content of comparison information 650 may be varied greatly depending upon the design criteria and anticipated performance/use of threat mitigation process 10. Accordingly, the appearance, format, completeness and content of comparison information 650 is for illustrative purposes only and is not intended to be a limitation of this disclosure, as other configurations are possible and are considered to be within the scope of this disclosure. For example, content may be added to comparison information 650, removed from comparison information 650, and/or reformatted within comparison information 650.

Referring also to FIG. 13 , threat mitigation process 10 may be configured to generate a threat context score for computing platform 60. As discussed above, threat mitigation process 10 may obtain 600 consolidated platform information to identify current security-relevant capabilities for computing platform 60. This consolidated platform information may be obtained from an independent information source (e.g., such as SIEM system 230 that may provide system-defined consolidated platform information 236) and/or may be obtained from a client information source (e.g., such as questionnaires 240 that may provide client-defined consolidated platform information 238. As will be discussed below in greater detail, threat mitigation process 10 may determine 700 comparative platform information that identifies security-relevant capabilities for a comparative platform, wherein this comparative platform information may concern vendor customers in a specific industry (i.e., the same industry as the user/owner/operator of computing platform 60) and/or vendor customers in any industry (i.e., not necessarily the same industry as the user/owner/operator of computing platform 60).

Referring also to FIG. 14 and as will be discussed below, threat mitigation process 10 may generate 702 comparison information 750 that compares the current security-relevant capabilities of computing platform 60 to the comparative platform information determined 700 for the comparative platform to identify a threat context indicator for computing platform 60, wherein comparison information 750 may include graphical comparison information 752.

Graphical comparison information 752 (which in this particular example is a bar chart) may identify one or more of: a current threat context score 754 for a client (e.g., the user/owner/operator of computing platform 60); a maximum possible threat context score 756 for the client (e.g., the user/owner/operator of computing platform 60); a threat context score 758 for one or more vendor customers in a specific industry (i.e., the same industry as the user/owner/operator of computing platform 60); and a threat context score 760 for one or more vendor customers in any industry (i.e., not necessarily the same industry as the user/owner/operator of computing platform 60).

Naturally, the format, appearance and content of comparison information 750 may be varied greatly depending upon the design criteria and anticipated performance/use of threat mitigation process 10. Accordingly, the appearance, format, completeness and content of comparison information 750 is for illustrative purposes only and is not intended to be a limitation of this disclosure, as other configurations are possible and are considered to be within the scope of this disclosure. For example, content may be added to comparison information 750, removed from comparison information 750, and/or reformatted within comparison information 750.

Computing Platform Monitoring & Mitigation

As will be discussed below in greater detail, threat mitigation process 10 may be configured to e.g., monitor the operation and performance of computing platform 60.

Referring also to FIG. 15 , threat mitigation process 10 may be configured to monitor the health of computing platform 60 and provide feedback to a third-party concerning the same. Threat mitigation process 10 may obtain 800 hardware performance information 244 concerning hardware (e.g., server computers, desktop computers, laptop computers, switches, firewalls, routers, gateways, WAPs, and NASs), deployed within computing platform 60. Hardware performance information 244 may concern the operation and/or functionality of one or more hardware systems (e.g., server computers, desktop computers, laptop computers, switches, firewalls, routers, gateways, WAPs, and NASs) deployed within computing platform 60.

Threat mitigation process 10 may obtain 802 platform performance information 246 concerning the operation of computing platform 60. Platform performance information 246 may concern the operation and/or functionality of computing platform 60.

When obtaining 802 platform performance information concerning the operation of computing platform 60, threat mitigation process 10 may (as discussed above): obtain 400 system-defined consolidated platform information 236 for computing platform 60 from an independent information source (e.g., SIEM system 230); obtain 312 client-defined consolidated platform information 238 for computing platform 60 from a client information (e.g., questionnaires 240); and present 450 differential consolidated platform information 352 for computing platform 60 to a third-party, examples of which may include but are not limited to the user/owner/operator of computing platform 60.

When obtaining 802 platform performance information concerning the operation of computing platform 60, threat mitigation process 10 may (as discussed above): obtain 500 consolidated platform information for computing platform 60 to identify one or more deployed security-relevant subsystems 226 (e.g., CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, antivirus systems, operating systems, data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform); process 506 the consolidated platform information (e.g., system-defined consolidated platform information 236 and/or client-defined consolidated platform information 238) to identify one or more non-deployed security-relevant subsystems (within computing platform 60); generate 508 a list of ranked & recommended security-relevant subsystems (e.g., non-deployed security-relevant subsystem list 550) that ranks the one or more non-deployed security-relevant subsystems; and provide 514 the list of ranked & recommended security-relevant subsystems (e.g., non-deployed security-relevant subsystem list 550) to a third-party, examples of which may include but are not limited to a user/owner/operator of computing platform 60.

When obtaining 802 platform performance information concerning the operation of computing platform 60, threat mitigation process 10 may (as discussed above): obtain 600 consolidated platform information to identify current security-relevant capabilities for the computing platform; determine 606 possible security-relevant capabilities for computing platform 60; and generate 608 comparison information 650 that compares the current security-relevant capabilities of computing platform 60 to the possible security-relevant capabilities of computing platform 60 to identify security-relevant deficiencies.

When obtaining 802 platform performance information concerning the operation of computing platform 60, threat mitigation process 10 may (as discussed above): obtain 600 consolidated platform information to identify current security-relevant capabilities for computing platform 60; determine 700 comparative platform information that identifies security-relevant capabilities for a comparative platform; and generate 702 comparison information 750 that compares the current security-relevant capabilities of computing platform 60 to the comparative platform information determined 700 for the comparative platform to identify a threat context indicator for computing platform 60.

Threat mitigation process 10 may obtain 804 application performance information 248 concerning one or more applications (e.g., operating systems, user applications, security application, and utility application) deployed within computing platform 60. Application performance information 248 may concern the operation and/or functionality of one or more software applications (e.g., operating systems, user applications, security application, and utility application) deployed within computing platform 60.

Referring also to FIG. 16 , threat mitigation process 10 may generate 806 holistic platform report (e.g., holistic platform reports 850, 852) concerning computing platform 60 based, at least in part, upon hardware performance information 244, platform performance information 246 and application performance information 248. Threat mitigation process 10 may be configured to receive e.g., hardware performance information 244, platform performance information 246 and application performance information 248 at regular intervals (e.g., continuously, every minute, every ten minutes, etc.).

As illustrated, holistic platform reports 850, 852 may include various pieces of content such as e.g., thought clouds that identity topics/issues with respect to computing platform 60, system logs that memorialize identified issues within computing platform 60, data sources providing information to computing system 60, and so on. The holistic platform report (e.g., holistic platform reports 850, 852) may identify one or more known conditions concerning the computing platform; and threat mitigation process 10 may effectuate 808 one or more remedial operations concerning the one or more known conditions.

For example, assume that the holistic platform report (e.g., holistic platform reports 850, 852) identifies that computing platform 60 is under a DoS (i.e., Denial of Services) attack. In computing, a denial-of-service attack (DoS attack) is a cyber-attack in which the perpetrator seeks to make a machine or network resource unavailable to its intended users by temporarily or indefinitely disrupting services of a host connected to the Internet. Denial of service is typically accomplished by flooding the targeted machine or resource with superfluous requests in an attempt to overload systems and prevent some or all legitimate requests from being fulfilled.

In response to detecting such a DoS attack, threat mitigation process 10 may effectuate 808 one or more remedial operations. For example and with respect to such a DoS attack, threat mitigation process 10 may effectuate 808 e.g., a remedial operation that instructs WAF (i.e., Web Application Firewall) 212 to deny all incoming traffic from the identified attacker based upon e.g., protocols, ports or the originating IP addresses.

Threat mitigation process 10 may also provide 810 the holistic report (e.g., holistic platform reports 850, 852) to a third-party, examples of which may include but are not limited to a user/owner/operator of computing platform 60.

Naturally, the format, appearance and content of the holistic platform report (e.g., holistic platform reports 850, 852) may be varied greatly depending upon the design criteria and anticipated performance/use of threat mitigation process 10. Accordingly, the appearance, format, completeness and content of the holistic platform report (e.g., holistic platform reports 850, 852) is for illustrative purposes only and is not intended to be a limitation of this disclosure, as other configurations are possible and are considered to be within the scope of this disclosure. For example, content may be added to the holistic platform report (e.g., holistic platform reports 850, 852), removed from the holistic platform report (e.g., holistic platform reports 850, 852), and/or reformatted within the holistic platform report (e.g., holistic platform reports 850, 852).

Referring also to FIG. 17 , threat mitigation process 10 may be configured to monitor computing platform 60 for the occurrence of a security event and (in the event of such an occurrence) gather artifacts concerning the same. For example, threat mitigation process 10 may detect 900 a security event within computing platform 60 based upon identified suspect activity. Examples of such security events may include but are not limited to: DDoS events, DoS events, phishing events, spamming events, malware events, web attacks, and exploitation events.

When detecting 900 a security event (e.g., DDoS events, DoS events, phishing events, spamming events, malware events, web attacks, and exploitation events) within computing platform 60 based upon identified suspect activity, threat mitigation process 10 may monitor 902 a plurality of sources to identify suspect activity within computing platform 60.

For example, assume that threat mitigation process 10 detects 900 a security event within computing platform 60. Specifically, assume that threat mitigation process 10 is monitoring 902 a plurality of sources (e.g., the various log files maintained by SIEM system 230). And by monitoring 902 such sources, assume that threat mitigation process 10 detects 900 the receipt of inbound content (via an API) from a device having an IP address located in Uzbekistan; the subsequent opening of a port within WAF (i.e., Web Application Firewall) 212; and the streaming of content from a computing device within computing platform 60 through that recently-opened port in WAF (i.e., Web Application Firewall) 212 and to a device having an IP address located in Moldova.

Upon detecting 900 such a security event within computing platform 60, threat mitigation process 10 may gather 904 artifacts (e.g., artifacts 250) concerning the above-described security event. When gathering 904 artifacts (e.g., artifacts 250) concerning the above-described security event, threat mitigation process 10 may gather 906 artifacts concerning the security event from a plurality of sources associated with the computing platform, wherein examples of such plurality of sources may include but are not limited to the various log files maintained by SIEM system 230, and the various log files directly maintained by the security-relevant subsystems.

Once the appropriate artifacts (e.g., artifacts 250) are gathered 904, threat mitigation process 10 may assign 908 a threat level to the above-described security event based, at least in part, upon the artifacts (e.g., artifacts 250) gathered 904.

When assigning 908 a threat level to the above-described security event, threat mitigation process 10 may assign 910 a threat level using artificial intelligence/machine learning. As discussed above and with respect to artificial intelligence/machine learning being utilized to process data sets, an initial probabilistic model may be defined, wherein this initial probabilistic model may be subsequently (e.g., iteratively or continuously) modified and revised, thus allowing the probabilistic models and the artificial intelligence systems (e.g., probabilistic process 56) to “learn” so that future probabilistic models may be more precise and may explain more complex data sets. As further discussed above, probabilistic process 56 may define an initial probabilistic model for accomplishing a defined task (e.g., the analyzing of information 58), wherein the probabilistic model may be utilized to go from initial observations about information 58 (e.g., as represented by the initial branches of a probabilistic model) to conclusions about information 58 (e.g., as represented by the leaves of a probabilistic model). Accordingly and through the use of probabilistic process 56, massive data sets concerning security events may be processed so that a probabilistic model may be defined (and subsequently revised) to assign 910 a threat level to the above-described security event.

Once assigned 910 a threat level, threat mitigation process 10 may execute 912 a remedial action plan (e., remedial action plan 252) based, at least in part, upon the assigned threat level.

For example and when executing 912 a remedial action plan, threat mitigation process 10 may allow 914 the above-described suspect activity to continue when e.g., threat mitigation process 10 assigns 908 a “low” threat level to the above-described security event (e.g., assuming that it is determined that the user of the local computing device is streaming video of his daughter's graduation to his parents in Moldova).

Further and when executing 912 a remedial action plan, threat mitigation process 10 may generate 916 a security event report (e.g., security event report 254) based, at least in part, upon the artifacts (e.g., artifacts 250) gathered 904; and provide 918 the security event report (e.g., security event report 254) to an analyst (e.g., analyst 256) for further review when e.g., threat mitigation process 10 assigns 908 a “moderate” threat level to the above-described security event (e.g., assuming that it is determined that while the streaming of the content is concerning, the content is low value and the recipient is not a known bad actor).

Further and when executing 912 a remedial action plan, threat mitigation process 10 may autonomously execute 920 a threat mitigation plan (shutting down the stream and closing the port) when e.g., threat mitigation process 10 assigns 908 a “severe” threat level to the above-described security event (e.g., assuming that it is determined that the streaming of the content is very concerning, as the content is high value and the recipient is a known bad actor).

Additionally, threat mitigation process 10 may allow 922 a third-party (e.g., the user/owner/operator of computing platform 60) to manually search for artifacts within computing platform 60. For example, the third-party (e.g., the user/owner/operator of computing platform 60) may be able to search the various information resources include within computing platform 60, examples of which may include but are not limited to the various log files maintained by SIEM system 230, and the various log files directly maintained by the security-relevant subsystems within computing platform 60.

Computing Platform Aggregation & Searching

As will be discussed below in greater detail, threat mitigation process 10 may be configured to e.g., aggregate data sets and allow for unified search of those data sets.

Referring also to FIG. 18 , threat mitigation process 10 may be configured to consolidate multiple separate and discrete data sets to form a single, aggregated data set. For example, threat mitigation process 10 may establish 950 connectivity with a plurality of security-relevant subsystems (e.g., security-relevant subsystems 226) within computing platform 60. As discussed above, examples of security-relevant subsystems 226 may include but are not limited to: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, Antivirus systems, operating systems, data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform.

When establishing 950 connectivity with a plurality of security-relevant subsystems, threat mitigation process 10 may utilize 952 at least one application program interface (e.g., API Gateway 224) to access at least one of the plurality of security-relevant subsystems. For example, a 1^(st) API gateway may be utilized to access CDN (i.e., Content Delivery Network) system; a 2^(nd) API gateway may be utilized to access DAM (i.e., Database Activity Monitoring) system; a 3^(rd) API gateway may be utilized to access UBA (i.e., User Behavior Analytics) system; a 4^(th) API gateway may be utilized to access MDM (i.e., Mobile Device Management) system; a 5^(th) API gateway may be utilized to access IAM (i.e., Identity and Access Management) system; and a 6^(th) API gateway may be utilized to access DNS (i.e., Domain Name Server) system.

Threat mitigation process 10 may obtain 954 at least one security-relevant information set (e.g., a log file) from each of the plurality of security-relevant subsystems (e.g., CDN system; DAM system; UBA system; MDM system; IAM system; and DNS system), thus defining plurality of security-relevant information sets 258. As would be expected, plurality of security-relevant information sets 258 may utilize a plurality of different formats and/or a plurality of different nomenclatures. Accordingly, threat mitigation process 10 may combine 956 plurality of security-relevant information sets 258 to form an aggregated security-relevant information set 260 for computing platform 60.

When combining 956 plurality of security-relevant information sets 258 to form aggregated security-relevant information set 260, threat mitigation process 10 may homogenize 958 plurality of security-relevant information sets 258 to form aggregated security-relevant information set 260. For example, threat mitigation process 10 may process one or more of security-relevant information sets 258 so that they all have a common format, a common nomenclature, and/or a common structure.

Once threat mitigation process 10 combines 956 plurality of security-relevant information sets 258 to form an aggregated security-relevant information set 260 for computing platform 60, threat mitigation process 10 may enable 960 a third-party (e.g., the user/owner/operator of computing platform 60) to access aggregated security-relevant information set 260 and/or enable 962 a third-party (e.g., the user/owner/operator of computing platform 60) to search aggregated security-relevant information set 260.

Referring also to FIG. 19 , threat mitigation process 10 may be configured to enable the searching of multiple separate and discrete data sets using a single search operation. For example and as discussed above, threat mitigation process 10 may establish 950 connectivity with a plurality of security-relevant subsystems (e., security-relevant subsystems 226) within computing platform 60. As discussed above, examples of security-relevant subsystems 226 may include but are not limited to: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, Antivirus systems, operating systems, data lakes; data logs, security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform.

When establishing 950 connectivity with a plurality of security-relevant subsystems, threat mitigation process 10 may utilize 952 at least one application program interface (e.g., API Gateway 224) to access at least one of the plurality of security-relevant subsystems. For example, a 1 API gateway may be utilized to access CDN (i.e., Content Delivery Network) system; a 2^(nd) API gateway may be utilized to access DAM (i.e., Database Activity Monitoring) system; a 3^(rd) API gateway may be utilized to access UBA (i.e., User Behavior Analytics) system; a 4^(th) API gateway may be utilized to access MDM (i.e., Mobile Device Management) system; a 5^(th) API gateway may be utilized to access IAM (i.e., Identity and Access Management) system; and a 6^(th) API gateway may be utilized to access DNS (i.e., Domain Name Server) system.

Threat mitigation process 10 may receive 1000 unified query 262 from a third-party (e.g., the user/owner/operator of computing platform 60) concerning the plurality of security-relevant subsystems. As discussed above, examples of security-relevant subsystems 226 may include but are not limited to: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, Antivirus systems, operating systems, data lakes; data logs, security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform.

Threat mitigation process 10 may distribute 1002 at least a portion of unified query 262 to the plurality of security-relevant subsystems, resulting in the distribution of plurality of queries 264 to the plurality of security-relevant subsystems. For example, assume that a third-party (e.g., the user/owner/operator of computing platform 60) wishes to execute a search concerning the activity of a specific employee. Accordingly, the third-party (e.g., the user/owner/operator of computing platform 60) may formulate the appropriate unified query (e.g., unified query 262) that defines the employee name, the computing device(s) of the employee, and the date range of interest. Unified query 262 may then be parsed to form plurality of queries 264, wherein a specific query (within plurality of queries 264) may be defined for each of the plurality of security-relevant subsystems and provided to the appropriate security-relevant subsystems. For example, a 1^(st) query may be included within plurality of queries 264 and provided to CDN (i.e., Content Delivery Network) system; a 2^(nd) query may be included within plurality of queries 264 and provided to DAM (i.e., Database Activity Monitoring) system; a 3^(rd) query may be included within plurality of queries 264 and provided to UBA (i.e., User Behavior Analytics) system; a 4^(th) query may be included within plurality of queries 264 and provided to MDM (i.e., Mobile Device Management) system; a 5^(th) query may be included within plurality of queries 264 and provided to IAM (i.e., Identity and Access Management) system; and a 6^(th) query may be included within plurality of queries 264 and provided to DNS (i.e., Domain Name Server) system.

Threat mitigation process 10 may effectuate 1004 at least a portion of unified query 262 on each of the plurality of security-relevant subsystems to generate plurality of result sets 266. For example, the 1^(st) query may be executed on CDN (i.e., Content Delivery Network) system to produce a 1^(st) result set; the 2^(nd) query may be executed on DAM (i.e., Database Activity Monitoring) system to produce a 2^(nd) result set; the 3^(rd) query may be executed on UBA (i.e., User Behavior Analytics) system to produce a 3^(rd) result set; the 4^(th) query may be executed on MDM (i.e., Mobile Device Management) system to produce a 4^(th) result set; the 5^(th) query may be executed on IAM (i.e., Identity and Access Management) system to produce a 5^(th) result set; and the 6^(th) query may executed on DNS (i.e., Domain Name Server) system to produce a 6^(h) result set.

Threat mitigation process 10 may receive 1006 plurality of result sets 266 from the plurality of security-relevant subsystems. Threat mitigation process 10 may then combine 1008 plurality of result sets 266 to form unified query result 268. When combining 1008 plurality of result sets 266 to form unified query result 268, threat mitigation process 10 may homogenize 1010 plurality of result sets 266 to form unified query result 268. For example, threat mitigation process 10 may process one or more discrete result sets included within plurality of result sets 266 so that the discrete result sets within plurality of result sets 266 all have a common format, a common nomenclature, and/or a common structure. Threat mitigation process 10 may then provide 1012 unified query result 268 to the third-party (e.g., the user/owner/operator of computing platform 60).

Referring also to FIG. 20 , threat mitigation process 10 may be configured to utilize artificial intelligence/machine learning to automatically consolidate multiple separate and discrete data sets to form a single, aggregated data set. For example and as discussed above, threat mitigation process 10 may establish 950 connectivity with a plurality of security-relevant subsystems (e.g., security-relevant subsystems 226) within computing platform 60. As discussed above, examples of security-relevant subsystems 226 may include but are not limited to: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, Antivirus systems, operating systems, data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform.

As discussed above and when establishing 950 connectivity with a plurality of security-relevant subsystems, threat mitigation process 10 may utilize 952 at least one application program interface (e.g., API Gateway 224) to access at least one of the plurality of security-relevant subsystems. For example, a 1^(st) API gateway may be utilized to access CDN (i.e., Content Delivery Network) system; a 2^(nd) API gateway may be utilized to access DAM (i.e., Database Activity Monitoring) system; a 3^(rd) API gateway may be utilized to access UBA (i.e., User Behavior Analytics) system; a 4^(th) API gateway may be utilized to access MDM (i.e., Mobile Device Management) system; a 5^(th) API gateway may be utilized to access IAM (i.e., Identity and Access Management) system; and a 6^(th) API gateway may be utilized to access DNS (i.e., Domain Name Server) system.

As discussed above, threat mitigation process 10 may obtain 954 at least one security-relevant information set (e.g., a log file) from each of the plurality of security-relevant subsystems (e.g., CDN system; DAM system; UBA system; MDM system; IAM system; and DNS system), thus defining plurality of security-relevant information sets 258. As would be expected, plurality of security-relevant information sets 258 may utilize a plurality of different formats and/or a plurality of different nomenclatures.

Threat mitigation process 10 may process 1050 plurality of security-relevant information sets 258 using artificial learning/machine learning to identify one or more commonalities amongst plurality of security-relevant information sets 258. As discussed above and with respect to artificial intelligence/machine learning being utilized to process data sets, an initial probabilistic model may be defined, wherein this initial probabilistic model may be subsequently (e.g., iteratively or continuously) modified and revised, thus allowing the probabilistic models and the artificial intelligence systems (e.g., probabilistic process 56) to “learn” so that future probabilistic models may be more precise and may explain more complex data sets. As further discussed above, probabilistic process 56 may define an initial probabilistic model for accomplishing a defined task (e.g., the analyzing of information 58), wherein the probabilistic model may be utilized to go from initial observations about information 58 (e.g., as represented by the initial branches of a probabilistic model) to conclusions about information 58 (e.g., as represented by the leaves of a probabilistic model). Accordingly and through the use of probabilistic process 56, plurality of security-relevant information sets 258 may be processed so that a probabilistic model may be defined (and subsequently revised) to identify one or more commonalities (e.g., common headers, common nomenclatures, common data ranges, common data types, common formats, etc.) amongst plurality of security-relevant information sets 258. When processing 1050 plurality of security-relevant information sets 258 using artificial learning/machine learning to identify one or more commonalities amongst plurality of security-relevant information sets 258, threat mitigation process 10 may utilize 1052 a decision tree (e.g., probabilistic model 100) based, at least in part, upon one or more previously-acquired security-relevant information sets.

Threat mitigation process 10 may combine 1054 plurality of security-relevant information sets 258 to form aggregated security-relevant information set 260 for computing platform 60 based, at least in part, upon the one or more commonalities identified.

When combining 1054 plurality of security-relevant information sets 258 to form aggregated security-relevant information set 260 for computing platform 60 based, at least in part, upon the one or more commonalities identified, threat mitigation process 10 may homogenize 1056 plurality of security-relevant information sets 258 to form aggregated security-relevant information set 260. For example, threat mitigation process 10 may process one or more of security-relevant information sets 258 so that they all have a common format, a common nomenclature, and/or a common structure.

Once threat mitigation process 10 combines 1054 plurality of security-relevant information sets 258 to form an aggregated security-relevant information set 260 for computing platform 60, threat mitigation process 10 may enable 1058 a third-party (e.g., the user/owner/operator of computing platform 60) to access aggregated security-relevant information set 260 and/or enable 1060 a third-party (e.g., the user/owner/operator of computing platform 60) to search aggregated security-relevant information set 260.

Threat Event Information Updating

As will be discussed below in greater detail, threat mitigation process 10 may be configured to be updated concerning threat event information.

Referring also to FIG. 21 , threat mitigation process 10 may be configured to receive updated threat event information for security-relevant subsystems 226. For example, threat mitigation process 10 may receive 1100 updated threat event information 270 concerning computing platform 60, wherein updated threat event information 270 may define one or more of: updated threat listings; updated threat definitions; updated threat methodologies; updated threat sources; and updated threat strategies. Threat mitigation process 10 may enable 1102 updated threat event information 270 for use with one or more security-relevant subsystems 226 within computing platform 60. As discussed above, examples of security-relevant subsystems 226 may include but are not limited to: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, Antivirus systems, operating systems, data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform.

When enabling 1102 updated threat event information 270 for use with one or more security-relevant subsystems 226 within computing platform 60, threat mitigation process 10 may install 1104 updated threat event information 270 on one or more security-relevant subsystems 226 within computing platform 60.

Threat mitigation process 10 may retroactively apply 1106 updated threat event information 270 to previously-generated information associated with one or more security-relevant subsystems 226.

When retroactively apply 1106 updated threat event information 270 to previously-generated information associated with one or more security-relevant subsystems 226, threat mitigation process 10 may: apply 1108 updated threat event information 270 to one or more previously-generated log files (not shown) associated with one or more security-relevant subsystems 226; apply 1110 updated threat event information 270 to one or more previously-generated data files (not shown) associated with one or more security-relevant subsystems 226; and apply 1112 updated threat event information 270 to one or more previously-generated application files (not shown) associated with one or more security-relevant subsystems 226.

Additionally, /alternatively, threat mitigation process 10 may proactively apply 1114 updated threat event information 270 to newly-generated information associated with one or more security-relevant subsystems 226.

When proactively applying 1114 updated threat event information 270 to newly-generated information associated with one or more security-relevant subsystems 226, threat mitigation process 10 may: apply 1116 updated threat event information 270 to one or more newly-generated log files (not shown) associated with one or more security-relevant subsystems 226; apply 1118 updated threat event information 270 to one or more newly-generated data files (not shown) associated with one or more security-relevant subsystems 226; and apply 1120 updated threat event information 270 to one or more newly-generated application files (not shown) associated with one or more security-relevant subsystems 226.

Referring also to FIG. 22 , threat mitigation process 10 may be configured to receive updated threat event information 270 for security-relevant subsystems 226. For example and as discussed above, threat mitigation process 10 may receive 1100 updated threat event information 270 concerning computing platform 60, wherein updated threat event information 270 may define one or more of: updated threat listings; updated threat definitions; updated threat methodologies; updated threat sources; and updated threat strategies. Further and as discussed above, threat mitigation process 10 may enable 1102 updated threat event information 270 for use with one or more security-relevant subsystems 226 within computing platform 60. As discussed above, examples of security-relevant subsystems 226 may include but are not limited to: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, Antivirus systems, operating systems, data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform.

As discussed above and when enabling 1102 updated threat event information 270 for use with one or more security-relevant subsystems 226 within computing platform 60, threat mitigation process 10 may install 1104 updated threat event information 270 on one or more security-relevant subsystems 226 within computing platform 60.

Sometimes, it may not be convenient and/or efficient to immediately apply updated threat event information 270 to security-relevant subsystems 226. Accordingly, threat mitigation process 10 may schedule 1150 the application of updated threat event information 270 to previously-generated information associated with one or more security-relevant subsystems 226.

When scheduling 1150 the application of updated threat event information 270 to previously-generated information associated with one or more security-relevant subsystems 226, threat mitigation process 10 may: schedule 1152 the application of updated threat event information 270 to one or more previously-generated log files (not shown) associated with one or more security-relevant subsystems 226; schedule 1154 the application of updated threat event information 270 to one or more previously-generated data files (not shown) associated with one or more security-relevant subsystems 226; and schedule 1156 the application of updated threat event information 270 to one or more previously-generated application files (not shown) associated with one or more security-relevant subsystems 226.

Additionally, /alternatively, threat mitigation process 10 may schedule 1158 the application of the updated threat event information to newly-generated information associated with the one or more security-relevant subsystems.

When scheduling 1158 the application of updated threat event information 270 to newly-generated information associated with one or more security-relevant subsystems 226, threat mitigation process 10 may: schedule 1160 the application of updated threat event information 270 to one or more newly-generated log files (not shown) associated with one or more security-relevant subsystems 226; schedule 1162 the application of updated threat event information 270 to one or more newly-generated data files (not shown) associated with one or more security-relevant subsystems 226; and schedule 1164 the application of updated threat event information 270 to one or more newly-generated application files (not shown) associated with one or more security-relevant subsystems 226.

Referring also to FIGS. 23-24 , threat mitigation process 10 may be configured to initially display analytical data, which may then be manipulated/updated to include automation data. For example, threat mitigation process 10 may display 1200 initial security-relevant information 1250 that includes analytical information (e.g., thought cloud 1252). Examples of such analytical information may include but is not limited to one or more of: investigative information; and hunting information.

Investigative Information (a portion of analytical information): Unified searching and/or automated searching, such as e.g., a security event occurring and searches being performed to gather artifacts concerning that security event.

Hunt Information (a portion of analytical information): Targeted searching/investigations, such as the monitoring and cataloging of the videos that an employee has watched or downloaded over the past 30 days.

Threat mitigation process 10 may allow 1202 a third-party (e.g., the user/owner/operator of computing platform 60) to manipulate initial security-relevant information 1250 with automation information.

Automate Information (a portion of automation). The execution of a single (and possibly simple) action one time, such as the blocking an IP address from accessing computing platform 60 whenever such an attempt is made.

Orchestrate Information (a portion of automation): The execution of a more complex batch (or series) of tasks, such as sensing an unauthorized download via an API and a) shutting down the API, adding the requesting IP address to a blacklist, and closing any ports opened for the requestor.

When allowing 1202 a third-party (e.g., the user/owner/operator of computing platform 60) to manipulate initial security-relevant information 1250 with automation information, threat mitigation process 10 may allow 1204 a third-party (e.g., the user/owner/operator of computing platform 60) to select the automation information to add to initial security-relevant information 1250 to generate revised security-relevant information 1250′. For example and when allowing 1204 a third-party (e.g., the user/owner/operator of computing platform 60) to select the automation information to add to initial security-relevant information 1250 to generate revised security-relevant information 1250′, threat mitigation process 10 may allow 1206 the third-party (e.g., the user/owner/operator of computing platform 60) to choose a specific type of automation information from a plurality of automation information types.

For example, the third-party (e.g., the user/owner/operator of computing platform 60) may choose to add/initiate the automation information to generate revised security-relevant information 1250′. Accordingly, threat mitigation process 10 may render selectable options (e.g., selectable buttons 1254, 1256) that the third-party (e.g., the user/owner/operator of computing platform 60) may select to manipulate initial security-relevant information 1250 with automation information to generate revised security-relevant information 1250′. For this particular example, the third-party (e.g., the user/owner/operator of computing platform 60) may choose two different options to manipulate initial security-relevant information 1250, namely: “block ip” or “search”, both of which will result in threat mitigation process 10 generating 1208 revised security-relevant information 1250′ (that includes the above-described automation information).

When generating 1208 revised security-relevant information 1250′ (that includes the above-described automation information), threat mitigation process 10 may combine 1210 the automation information (that results from selecting “block IP” or “search”) and initial security-relevant information 1250 to generate and render 1212 revised security-relevant information 1250′.

When rendering 1212 revised security-relevant information 1250′, threat mitigation process 10 may render 1214 revised security-relevant information 1250′ within interactive report 1258.

Training Routine Generation and Execution

As will be discussed below in greater detail, threat mitigation process 10 may be configured to allow for the manual or automatic generation of training routines, as well as the execution of the same.

Referring also to FIG. 25 , threat mitigation process 10 may be configured to allow for the manual generation of testing routine 272. For example, threat mitigation process 10 may define 1300 training routine 272 for a specific attack (e.g., a Denial of Services attack) of computing platform 60. Specifically, threat mitigation process 10 may generate 1302 a simulation of the specific attack (e.g., a Denial of Services attack) by executing training routine 272 within a controlled test environment, an example of which may include but is not limited to virtual machine 274 executed on a computing device (e.g., computing device 12).

When generating 1302 a simulation of the specific attack (e.g., a Denial of Services attack) by executing training routine 272 within the controlled test environment (e.g., virtual machine 274), threat mitigation process 10 may render 1304 the simulation of the specific attack (e.g., a Denial of Services attack) on the controlled test environment (e.g., virtual machine 274).

Threat mitigation process 10 may allow 1306 a trainee (e.g., trainee 276) to view the simulation of the specific attack (e.g., a Denial of Services attack) and may allow 1308 the trainee (e.g., trainee 276) to provide a trainee response (e.g., trainee response 278) to the simulation of the specific attack (e.g., a Denial of Services attack). For example, threat mitigation process 10 may execute training routine 272, which trainee 276 may “watch” and provide trainee response 278.

Threat mitigation process 10 may then determine 1310 the effectiveness of trainee response 278, wherein determining 1310 the effectiveness of the trainee response may include threat mitigation process 10 assigning 1312 a grade (e.g., a letter grade or a number grade) to trainee response 278.

Referring also to FIG. 26 , threat mitigation process 10 may be configured to allow for the automatic generation of testing routine 272. For example, threat mitigation process 10 may utilize 1350 artificial intelligence/machine learning to define training routine 272 for a specific attack (e.g., a Denial of Services attack) of computing platform 60.

As discussed above and with respect to artificial intelligence/machine learning being utilized to process data sets, an initial probabilistic model may be defined, wherein this initial probabilistic model may be subsequently (e.g., iteratively or continuously) modified and revised, thus allowing the probabilistic models and the artificial intelligence systems (e.g., probabilistic process 56) to “learn” so that future probabilistic models may be more precise and may explain more complex data sets. As further discussed above, probabilistic process 56 may define an initial probabilistic model for accomplishing a defined task (e.g., the analyzing of information 58), wherein the probabilistic model may be utilized to go from initial observations about information 58 (e.g., as represented by the initial branches of a probabilistic model) to conclusions about information 58 (e.g., as represented by the leaves of a probabilistic model). Accordingly and through the use of probabilistic process 56, information may be processed so that a probabilistic model may be defined (and subsequently revised) to define training routine 272 for a specific attack (e.g., a Denial of Services attack) of computing platform 60.

When using 1350 artificial intelligence/machine learning to define training routine 272 for a specific attack (e.g., a Denial of Services attack) of computing platform 60, threat mitigation process 10 may process 1352 security-relevant information to define training routine 272 for specific attack (e.g., a Denial of Services attack) of computing platform 60. Further and when using 1350 artificial intelligence/machine learning to define training routine 272 for a specific attack (e.g., a Denial of Services attack) of computing platform 60, threat mitigation process 10 may utilize 1354 security-relevant rules to define training routine 272 for a specific attack (e.g., a Denial of Services attack) of computing platform 60. Accordingly, security-relevant information that e.g., defines the symptoms of e.g., a Denial of Services attack and security-relevant rules that define the behavior of e.g., a Denial of Services attack may be utilized by threat mitigation process 10 when defining training routine 272.

As discussed above, threat mitigation process 10 may generate 1302 a simulation of the specific attack (e.g., a Denial of Services attack) by executing training routine 272 within a controlled test environment, an example of which may include but is not limited to virtual machine 274 executed on a computing device (e.g., computing device 12.

Further and as discussed above, when generating 1302 a simulation of the specific attack (e.g., a Denial of Services attack) by executing training routine 272 within the controlled test environment (e.g., virtual machine 274), threat mitigation process 10 may render 1304 the simulation of the specific attack (e.g., a Denial of Services attack) on the controlled test environment (e.g., virtual machine 274).

Threat mitigation process 10 may allow 1306 a trainee (e.g., trainee 276) to view the simulation of the specific attack (e.g., a Denial of Services attack) and may allow 1308 the trainee (e.g., trainee 276) to provide a trainee response (e.g., trainee response 278) to the simulation of the specific attack (e.g., a Denial of Services attack). For example, threat mitigation process 10 may execute training routine 272, which trainee 276 may “watch” and provide trainee response 278.

Threat mitigation process 10 may utilize 1356 artificial intelligence/machine learning to revise training routine 272 for the specific attack (e.g., a Denial of Services attack) of computing platform 60 based, at least in part, upon trainee response 278.

As discussed above, threat mitigation process 10 may then determine 1310 the effectiveness of trainee response 278, wherein determining 1310 the effectiveness of the trainee response may include threat mitigation process 10 assigning 1312 a grade (e.g., a letter grade or a number grade) to trainee response 278.

Referring also to FIG. 27 , threat mitigation process 10 may be configured to allow a trainee to choose their training routine. For example mitigation process 10 may allow 1400 a third-party (e.g., the user/owner/operator of computing platform 60) to select a training routine for a specific attack (e.g., a Denial of Services attack) of computing platform 60, thus defining a selected training routine. When allowing 1400 a third-party (e.g., the user/owner/operator of computing platform 60) to select a training routine for a specific attack (e.g., a Denial of Services attack) of computing platform 60, threat mitigation process 10 may allow 1402 the third-party (e.g., the user/owner/operator of computing platform 60) to choose a specific training routine from a plurality of available training routines. For example, the third-party (e.g., the user/owner/operator of computing platform 60) may be able to select a specific type of attack (e.g., DDoS events, DoS events, phishing events, spamming events, malware events, web attacks, and exploitation events) and/or select a specific training routine (that may or may not disclose the specific type of attack).

Once selected, threat mitigation process 10 may analyze 1404 the requirements of the selected training routine (e.g., training routine 272) to determine a quantity of entities required to effectuate the selected training routine (e.g., training routine 272), thus defining one or more required entities. For example, assume that training routine 272 has three required entities (e.g., an attacked device and two attacking devices). According, threat mitigation process 10 may generate 1406 one or more virtual machines (e.g., such as virtual machine 274) to emulate the one or more required entities. In this particular example, threat mitigation process 10 may generate 1406 three virtual machines, a first VM for the attacked device, a second VM for the first attacking device and a third VM for the second attacking device. As is known in the art, a virtual machine (VM) is a virtual emulation of a physical computing system. Virtual machines may be based on computer architectures and may provide the functionality of a physical computer, wherein their implementations may involve specialized hardware, software, or a combination thereof.

Threat mitigation process 10 may generate 1408 a simulation of the specific attack (e.g., a Denial of Services attack) by executing the selected training routine (e.g., training routine 272). When generating 1408 the simulation of the specific attack (e.g., a Denial of Services attack) by executing the selected training routine (e.g., training routine 272), threat mitigation process 10 may render 1410 the simulation of the specific attack (e.g., a Denial of Services attack) by executing the selected training routine (e.g., training routine 272) within a controlled test environment (e.g., such as virtual machine 274).

As discussed above, threat mitigation process 10 may allow 1306 a trainee (e.g., trainee 276) to view the simulation of the specific attack (e.g., a Denial of Services attack) and may allow 1308 the trainee (e.g., trainee 276) to provide a trainee response (e.g., trainee response 278) to the simulation of the specific attack (e.g., a Denial of Services attack). For example, threat mitigation process 10 may execute training routine 272, which trainee 276 may “watch” and provide trainee response 278.

Further and as discussed above, threat mitigation process 10 may then determine 1310 the effectiveness of trainee response 278, wherein determining 1310 the effectiveness of the trainee response may include threat mitigation process 10 assigning 1312 a grade (e.g., a letter grade or a number grade) to trainee response 278.

When training is complete, threat mitigation process 10 may cease 1412 the simulation of the specific attack (e.g., a Denial of Services attack), wherein ceasing 1412 the simulation of the specific attack (e.g., a Denial of Services attack) may include threat mitigation process 10 shutting down 1414 the one or more virtual machines (e.g., the first VM for the attacked device, the second VM for the first attacking device and the third VM for the second attacking device).

Information Routing

As will be discussed below in greater detail, threat mitigation process 10 may be configured to route information based upon whether the information is more threat-pertinent or less threat-pertinent.

Referring also to FIG. 28 , threat mitigation process 10 may be configured to route more threat-pertinent content in a specific manner. For example, threat mitigation process 10 may receive 1450 platform information (e.g., log files) from a plurality of security-relevant subsystems (e.g., security-relevant subsystems 226). As discussed above, examples of security-relevant subsystems 226 may include but are not limited to: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, Antivirus systems, operating systems, data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform.

Threat mitigation process 10 may process 1452 this platform information (e.g., log files) to generate processed platform information. And when processing 1452 this platform information (e.g., log files) to generate processed platform information, threat mitigation process 10 may: parse 1454 the platform information (e.g., log files) into a plurality of subcomponents (e.g., columns, rows, etc.) to allow for compensation of varying formats and/or nomenclature; enrich 1456 the platform information (e.g., log files) by including supplemental information from external information resources; and/or utilize 1458 artificial intelligence/machine learning (in the manner described above) to identify one or more patterns/trends within the platform information (e.g., log files).

Threat mitigation process 10 may identify 1460 more threat-pertinent content 280 included within the processed content, wherein identifying 1460 more threat-pertinent content 280 included within the processed content may include processing 1462 the processed content to identify actionable processed content that may be used by a threat analysis engine (e.g., SIEM system 230) for correlation purposes. Threat mitigation process 10 may route 1464 more threat-pertinent content 280 to this threat analysis engine (e.g., SIEM system 230).

Referring also to FIG. 29 , threat mitigation process 10 may be configured to route less threat-pertinent content in a specific manner. For example and as discussed above, threat mitigation process 10 may receive 1450 platform information (e.g., log files) from a plurality of security-relevant subsystems (e.g., security-relevant subsystems 226). As discussed above, examples of security-relevant subsystems 226 may include but are not limited to: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, Antivirus systems, operating systems, data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform

Further and as discussed above, threat mitigation process 10 may process 1452 this platform information (e.g., log files) to generate processed platform information. And when processing 1452 this platform information (e.g., log files) to generate processed platform information, threat mitigation process 10 may: parse 1454 the platform information (e.g., log files) into a plurality of subcomponents (e.g., columns, rows, etc.) to allow for compensation of varying formats and/or nomenclature; enrich 1456 the platform information (e.g., log files) by including supplemental information from external information resources; and/or utilize 1458 artificial intelligence/machine learning (in the manner described above) to identify one or more patterns/trends within the platform information (e.g., log files).

Threat mitigation process 10 may identify 1500 less threat-pertinent content 282 included within the processed content, wherein identifying 1500 less threat-pertinent content 282 included within the processed content may include processing 1502 the processed content to identify non-actionable processed content that is not usable by a threat analysis engine (e.g., SIEM system 230) for correlation purposes. Threat mitigation process 10 may route 1504 less threat-pertinent content 282 to a long-term storage system (e.g., long term storage system 284). Further, threat mitigation process 10 may be configured to allow 1506 a third-party (e.g., the user/owner/operator of computing platform 60) to access and search long term storage system 284.

Automated Analysis

As will be discussed below in greater detail, threat mitigation process 10 may be configured to automatically analyze a detected security event.

Referring also to FIG. 30 , threat mitigation process 10 may be configured to automatically classify and investigate a detected security event. As discussed above and in response to a security event being detected, threat mitigation process 10 may obtain 1550 one or more artifacts (e.g., artifacts 250) concerning the detected security event. Examples of such a detected security event may include but are not limited to one or more of: access auditing; anomalies; authentication; denial of services; exploitation; malware; phishing; spamming; reconnaissance; and web attack. These artifacts (e.g., artifacts 250) may be obtained 1550 from a plurality of sources associated with the computing platform, wherein examples of such plurality of sources may include but are not limited to the various log files maintained by SIEM system 230, and the various log files directly maintained by the security-relevant subsystems

Threat mitigation process 10 may obtain 1552 artifact information (e.g., artifact information 286) concerning the one or more artifacts (e.g., artifacts 250), wherein artifact information 286 may be obtained from information resources include within (or external to) computing platform 60.

For example and when obtaining 1552 artifact information 286 concerning the one or more artifacts (e.g., artifacts 250), threat mitigation process 10 may obtain 1554 artifact information 286 concerning the one or more artifacts (e.g., artifacts 250) from one or more investigation resources (such as third-party resources that may e.g., provide information on known bad actors).

Once the investigation is complete, threat mitigation process 10 may generate 1556 a conclusion (e.g., conclusion 288) concerning the detected security event (e.g., a Denial of Services attack) based, at least in part, upon the detected security event (e.g., a Denial of Services attack), the one or more artifacts (e.g., artifacts 250), and artifact information 286. Threat mitigation process 10 may document 1558 the conclusion (e.g., conclusion 288), report 1560 the conclusion (e.g., conclusion 288) to a third-party (e.g., the user/owner/operator of computing platform 60). Further, threat mitigation process 10 may obtain 1562 supplemental artifacts and artifact information (if needed to further the investigation).

While the system is described above as being computer-implemented, this is for illustrative purposes only and is not intended to be a limitation of this disclosure, as other configurations are possible and are considered to be within the scope of this disclosure. For example, some or all of the above-described system may be implemented by a human being.

Unified Searching

As discussed above, threat mitigation process 10 may be configured to e.g., analyze a monitored computing platform (e.g., computing platform 60) and provide information to third-parties concerning the same. Further and as discussed above, such a monitored computing platform (e.g., computing platform 60) may be a highly complex, multi-location computing system/network that may span multiple buildings/locations/countries.

For this illustrative example, the monitored computing platform (e.g., computing platform 60) is shown to include many discrete computing devices, examples of which may include but are not limited to: server computers (e.g., server computers 200, 202), desktop computers (e.g., desktop computer 204), and laptop computers (e.g., laptop computer 206), all of which may be coupled together via a network (e.g., network 208), such as an Ethernet network. Computing platform 60 may be coupled to an external network (e.g., Internet 210) through WAF (i.e., Web Application Firewall) 212. A wireless access point (e.g., WAP 214) may be configured to allow wireless devices (e.g., smartphone 216) to access computing platform 60. Computing platform 60 may include various connectivity devices that enable the coupling of devices within computing platform 60, examples of which may include but are not limited to: switch 216, router 218 and gateway 220. Computing platform 60 may also include various storage devices (e.g., NAS 222), as well as functionality (e.g., API Gateway 224) that allows software applications to gain access to one or more resources within computing platform 60.

In addition to the devices and functionality discussed above, other technology (e.g., security-relevant subsystems 226) may be deployed within computing platform 60 to monitor the operation of (and the activity within) computing platform 60. Examples of security-relevant subsystems 226 may include but are not limited to: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, antivirus systems, operating systems, data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform. Each of security-relevant subsystems 226 may monitor and log their activity with respect to computing platform 60, resulting in the generation of platform information 228. For example, platform information 228 associated with a client-defined MDM (i.e., Mobile Device Management) system may monitor and log the mobile devices that were allowed access to computing platform 60.

Further, SELM (i.e., Security Information and Event Management) system 230 may be deployed within computing platform 60. As is known in the art, SIEM system 230 is an approach to security management that combines SIM (security information management) functionality and SEM (security event management) functionality into one security management system. The underlying principles of a SIEM system is to aggregate relevant data from multiple sources, identify deviations from the norm and take appropriate action. For example, when a security event is detected, SIEM system 230 might log additional information, generate an alert and instruct other security controls to mitigate the security event. Accordingly, SIEM system 230 may be configured to monitor and log the activity of security-relevant subsystems 226 (e.g., CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, antivirus systems, operating systems, data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform).

Referring also to FIGS. 31-32 , threat mitigation process 10 may be configured to enable the querying of multiple separate and discrete subsystems (e.g., security-relevant subsystems 226) using a single query operation. For example, threat mitigation process 10 may establish 1600 connectivity with a plurality of security-relevant subsystems (e.g., security-relevant subsystems 226) within computing platform 60.

As discussed above, examples of security-relevant subsystems 226 may include but are not limited to: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, Antivirus systems, operating systems, data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform.

When establishing 1600 connectivity with a plurality of security-relevant subsystems (e.g., security-relevant subsystems 226), threat mitigation process 10 may utilize at least one application program interface (e.g., API Gateway 224) to access at least one of the plurality of security-relevant subsystems. For example, a 1^(st) API gateway may be utilized to access CDN (i.e., Content Delivery Network) system; a 2^(nd) API gateway may be utilized to access DAM (i.e., Database Activity Monitoring) system; a 3^(rd) API gateway may be utilized to access UBA (i.e., User Behavior Analytics) system; a 4^(th) API gateway may be utilized to access MDM (i.e., Mobile Device Management) system; a 5^(th) API gateway may be utilized to access IAM (i.e., Identity and Access Management) system; and a 6^(th) API gateway may be utilized to access DNS (i.e., Domain Name Server) system.

In order to enable the querying of multiple separate and discrete subsystems (e.g., security-relevant subsystems 226) using a single query operation, threat mitigation process 10 may map 1602 one or more data fields of unified platform 290 (e.g., a platform effectuated by threat mitigation process 10) to one or more data fields of each of the plurality of security-relevant subsystems (e.g., security-relevant subsystems 226).

For example, unified platform 290 may be a platform that enables a third-party (e.g., the user/owner/operator of computing platform 60) to query multiple security-relevant subsystems (within security-relevant subsystems 226), such as security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654. As discussed above, examples of such security-relevant subsystem (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654) may include but are not limited to: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, antivirus systems, operating systems, data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform.

Each of these security-relevant subsystem (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654) may include a plurality of data fields that enable the third-party (e.g., the user/owner/operator of computing platform 60) to search for and obtain information from these security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654). For example: security-relevant subsystem 1650 is shown to include data fields 1656, 1658, 1660, 1662; security-relevant subsystem 1652 is shown to include data fields 1664, 1666, 1668, 1670; and security-relevant subsystem 1654 is shown to include data fields 1672, 1674, 1676, 1678.

These data fields (e.g., data fields 1656, 1658, 1660, 1662, 1664, 1666, 1668, 1670, 1672, 1674, 1676, 1678) may be populatable by the third-party (e.g., the user/owner/operator of computing platform 60) to enable such searching. For example, the third-party (e.g., the user/owner/operator of computing platform 60) may populate these data fields by typing information into some of these data fields (e.g., data fields 1656, 1658, 1660, 1666, 1668, 1670, 1672, 1674, 1676). Additionally/alternatively, the third-party (e.g., the user/owner/operator of computing platform 60) may populate these data fields via a drop-down menu available within some of these data fields (e.g., data fields 1662, 1664, 1678). For example, data field 1662 is shown to be populatable via drop down menu 1680, data field 1664 is shown to be populatable via drop down menu 1682, and data field 1678 is shown to be populatable via drop down menu 1684.

Through the use of such data fields, the third-party (e.g., the user/owner/operator of computing platform 60) may populate one of more of these data fields to define a query that may be effectuated on the information contained/available within these security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654) so that the pertinent information may be obtained.

Naturally, the subject matter of these individual data fields may vary depending upon the type of information available via these security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654). As (in this example) these are security-relevant subsystems, the information available from these security-relevant subsystems concerns the security of computing platform 60 and/or any security events (e.g., access auditing, anomalies; authentication; denial of services; exploitation; malware; phishing; spamming; reconnaissance; and/or web attack) occurring therein. For example, some of these data fields may concern e.g., user names, user IDs, device locations, device types, device IP addresses, source IP addresses, destination IP addresses, port addresses, deployed operating systems, utilized bandwidth, etc.

As discussed above, in order to enable the querying of multiple separate and discrete subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654) using a single query operation, threat mitigation process 10 may map 1602 one or more data fields of unified platform 290 (e.g., a platform effectuated by threat mitigation process 10) to one or more data fields of each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654).

In this particular example, unified platform 290 (e.g., a platform effectuated by threat mitigation process 10) is shown to include four data fields (e.g., data fields 1686, 1688, 1690, 1692), wherein:

-   -   data field 1686 within unified platform 290 concerns a user ID         (and is entitled USER_ID);     -   data field 1688 within unified platform 290 concerns a device IP         address (and is entitled DEVICE_IP);     -   data field 1690 within unified platform 290 concerns a         destination IP address (and is entitled DESTINATION_IP); and     -   data field 1692 within unified platform 290 concerns a query         result set (and is entitled QUERY_RESULT).

When mapping 1602 data fields within unified platform 290 (e.g., a platform effectuated by threat mitigation process 10) to data fields within each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654), threat mitigation process 10 may only map 1602 data fields that are related with respect to subject matter.

As discussed above, data field 1686 within unified platform 290 (e.g., a platform effectuated by threat mitigation process 10) concerns a user ID (and is entitled USER_ID). For this example, assume that:

-   -   data field 1656 within security-relevant subsystem 1650 also         concerns a user ID and is entitled USER;     -   data field 1666 within security-relevant subsystem 1652 also         concerns a user ID and is entitled ID; and     -   data field 1676 within security-relevant subsystem 1654 also         concerns a user ID and is entitled USR_ID.

Accordingly, threat mitigation process 10 may map 1602 data field 1686 of unified platform 290 (e.g., a platform effectuated by threat mitigation process 10) to:

-   -   data field 1656 of security-relevant subsystem 1650;     -   data field 1666 of security-relevant subsystem 1652; and     -   data field 1676 of security-relevant subsystem 1654.

As discussed above, data field 1688 within unified platform 290 (e.g., a platform effectuated by threat mitigation process 10) concerns a device IP address (and is entitled DEVICE_IP). For this example, assume that:

-   -   data field 1660 within security-relevant subsystem 1650 also         concerns a device IP address and is entitled DEV_IP;     -   data field 1670 within security-relevant subsystem 1652 also         concerns a device IP address and is entitled IP_DEVICE; and     -   data field 1674 within security-relevant subsystem 1654 also         concerns a device IP address and is entitled IP_DEV.

Accordingly, threat mitigation process 10 may map 1602 data field 1688 of unified platform 290 (e.g., a platform effectuated by threat mitigation process 10) to:

-   -   data field 1660 of security-relevant subsystem 1650;     -   data field 1670 of security-relevant subsystem 1652; and     -   data field 1674 of security-relevant subsystem 1654.

As discussed above, data field 1690 within unified platform 290 (e.g., a platform effectuated by threat mitigation process 10) concerns a destination IP address (and is entitled DESTINATION_IP). For this example, assume that:

-   -   data field 1658 within security-relevant subsystem 1650 also         concerns a destination IP address and is entitled DEST_IP;     -   data field 1668 within security-relevant subsystem 1652 also         concerns a destination IP address and is entitled IP_DEST; and     -   data field 1672 within security-relevant subsystem 1654 also         concerns a destination IP address and is entitled IP_DES.

Accordingly, threat mitigation process 10 may map 1602 data field 1690 of unified platform 290 (e.g., a platform effectuated by threat mitigation process 10) to:

-   -   data field 1658 of security-relevant subsystem 1650;     -   data field 1668 of security-relevant subsystem 1652; and     -   data field 1672 of security-relevant subsystem 1654.

As discussed above, data field 1692 within unified platform 290 (e.g., a platform effectuated by threat mitigation process 10) concerns a query result (and is entitled QUERY_RESULT). For this example, assume that:

-   -   data field 1662 within security-relevant subsystem 1650 also         concerns a query result and is entitled RESULT;     -   data field 1664 within security-relevant subsystem 1652 also         concerns a query result and is entitled Q_RESULT; and     -   data field 1678 within security-relevant subsystem 1654 also         concerns a query result and is entitled RESULT_Q.

Accordingly, threat mitigation process 10 may map 1602 data field 1692 of unified platform 290 (e.g., a platform effectuated by threat mitigation process 10) to:

-   -   data field 1662 of security-relevant subsystem 1650.     -   data field 1664 of security-relevant subsystem 1652; and     -   data field 1678 of security-relevant subsystem 1654.

Through the use of threat mitigation process 10, a query (e.g., query 1694) may be defined within one or more of data fields 1686, 1688, 1690 of unified platform 290 (e.g., a platform effectuated by threat mitigation process 10), wherein this query (e.g., query 1694) may be provided (via the above-described mappings) to the appropriate data fields within the security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654).

Accordingly and when mapping 1602 one or more data fields of the unified platform (e.g., unified platform 290) to one or more data fields of each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654), threat mitigation process 10 may map 1604 one or more data fields within a query structure of the unified platform (e.g., unified platform 290) to one or more data fields within a query structure of each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654).

Therefore, if a query (e.g., query 1694) was defined on unified platform 290 (e.g., a platform effectuated by threat mitigation process 10) that specified a user ID within data field 1686, a device IP address within data field 1688, and a destination IP address within data field 1690; by mapping 1604 one or more data fields of the unified platform (e.g., unified platform 290) to one or more data fields of each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654), this structured query (e.g., query 1694) may be provided to the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654) in a fashion that enables the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654) to effectuate the structured query (e.g., query 1694).

Upon effectuating such a structured query (e.g., query 1694), the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654) may each generate a subsystem-specific result set. For example, security-relevant subsystem 1650 may generate subsystem-specific result set 1696, security-relevant subsystem 1652 may generate subsystem-specific result set 1698, and security-relevant subsystem 1654 may generate subsystem-specific result set 1700.

Through the use of threat mitigation process 10, subsystem-specific result sets (e.g., subsystem-specific result sets 1696, 1698, 1700) may be defined within one or more of data fields (e.g., data fields 1662, 1664, 1678) of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654), wherein these subsystem-specific result sets (e.g., subsystem-specific result sets 1696, 1698, 1700) may be provided (via the above-described mappings) to the appropriate data fields within the unified platform (e.g., unified platform 290).

Accordingly and when mapping 1602 one or more data fields of the unified platform (e.g., unified platform 290) to one or more data fields of each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654), threat mitigation process 10 may map 1606 one or more data fields within a result set structure of each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654) to one or more data fields within a result set structure of the unified platform (e.g., unified platform 290).

Therefore, by mapping 1606 one or more data fields within a result set structure of each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654) to one or more data fields within a result set structure of the unified platform (e.g., unified platform 290), these subsystem-specific result sets (e.g., subsystem-specific result sets 1696, 1698, 1700) may be provided to the unified platform (e.g., unified platform 290) in a fashion that enables the unified platform (e.g., unified platform 290) to properly process these subsystem-specific result sets (e.g., subsystem-specific result sets 1696, 1698, 1700).

It is foreseeable that over time, the data fields within the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654) may change. For example, additional data fields may be added to and/or certain data fields may be deleted from the plurality of security-relevant subsystems. Accordingly and in order to ensure that the above-described mapping remain current and accurate, such mappings may be periodically refreshed.

Accordingly and when mapping 1602 one or more data fields of the unified platform (e.g., unified platform 290) to one or more data fields of each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654), threat mitigation process 10 may map 1608 one or more data fields of the unified platform (e.g., unified platform 290) to one or more data fields of each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654) at a defined periodicity.

Therefore, at a certain frequency (e.g., every few minutes, every few hours, every few days, every few weeks or every few months), the above-describe mapping process may be reperformed to ensure that the above-described mappings are up to date.

Further and when mapping 1602 one or more data fields of the unified platform (e.g., unified platform 290) to one or more data fields of each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654), threat mitigation process 10 may proactively map 1610 one or more data fields of the unified platform (e.g., unified platform 290) to one or more data fields of each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654).

For example, the above-described mapping process may be proactively done, wherein threat mitigation process 10 actively monitors the security-relevant subsystems within computing platform 60 so that the data fields within these security-relevant subsystems may be proactively mapped 1610 prior to a third-party (e.g., the user/owner/operator of computing platform 60) defining a query within unified platform 290.

Additionally and when mapping 1602 one or more data fields of the unified platform (e.g., unified platform 290) to one or more data fields of each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654), threat mitigation process 10 may reactively map 1612 one or more data fields of the unified platform (e.g., unified platform 290) to one or more data fields of each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654).

For example, the above-described mapping process may be reactively performed, wherein threat mitigation process 10 may not actively monitor the security-relevant subsystems within computing platform 60 and the data fields within these security-relevant subsystems may be reactively mapped 1612 after a third-party (e.g., the user/owner/operator of computing platform 60) defines a query within unified platform 290.

As discussed above, threat mitigation process 10 may allow a third-party (e.g., the user/owner/operator of computing platform 60) to define 1614 a unified query (e.g., query 1694) on a unified platform (e.g., unified platform 290) concerning security-relevant subsystems 226 (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654).

As discussed above, examples of security-relevant subsystems 226 may include but are not limited to: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, Antivirus systems, operating systems, data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform.

Threat mitigation process 10 may denormalize 1616 the unified query (e.g., query 1694) to define a subsystem-specific query for each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654), thus defining a plurality of subsystem-specific queries (e.g., subsystem-specific queries 1702, 1704, 1706).

As discussed above, unified platform 290 (e.g., a platform effectuated by threat mitigation process 10) is shown to include four data fields (e.g., data fields 1686, 1688, 1690, 1692), wherein a third-party (e.g., the user/owner/operator of computing platform 60) may utilize these data fields to define the unified query (e.g., query 1694). As this unified query (e.g., query 1694) may be used as the basis to search for pertinent information on (in this example) three entirely separate and discrete subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654), it is foreseeable that these subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654) may require queries to be structured differently.

Accordingly and when denormalizing 1616 the unified query (e.g., query 1694) to define a subsystem-specific query for each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654), thus defining a plurality of subsystem-specific queries (e.g., subsystem-specific queries 1702, 1704, 1706), threat mitigation process 10 may translate 1618 a syntax of the unified query (e.g., query 1694) to a syntax of each of the plurality of subsystem-specific queries (e.g., subsystem-specific queries 1702, 1704, 1706). For example:

-   -   security-relevant subsystem 1650 may only be capable of         processing queries having a first structure and/or utilizing a         first nomenclature;     -   a security-relevant subsystem 1652 may only be capable of         processing queries having a second structure and/or utilizing a         second nomenclature; and     -   security-relevant subsystem 1654 may only be capable of         processing queries having a third structure and/or utilizing a         third nomenclature.

Accordingly and when denormalizing 1616 the unified query (e.g., query 1694) to define a plurality of subsystem-specific queries (e.g., subsystem-specific queries 1702, 1704, 1706), threat mitigation process 10 may translate 1618 the syntax of the unified query (e.g., query 1694) so that:

-   -   subsystem-specific query 1702 has a first structure and/or         utilizes a first nomenclature;     -   subsystem-specific query 1704 has a second structure and/or         utilizes a second nomenclature;     -   subsystem-specific query 1706 has a third structure and/or         utilizes a third nomenclature.

Threat mitigation process 10 may provide 1620 the plurality of subsystem-specific queries (e.g., subsystem-specific queries 1702, 1704, 1706) to the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654).

The plurality of subsystem-specific queries (e.g., subsystem-specific queries 1702, 1704, 1706) may be effectuated on the appropriate security-relevant subsystem. For example, subsystem-specific query 1702 may be effectuated on security-relevant subsystem 1650, subsystem-specific query 1704 may be effectuated on security-relevant subsystem 1652, and subsystem-specific query 1706 may be effectuated on security-relevant subsystem 1654; resulting in the generation of subsystem-specific result sets. For example, security-relevant subsystem 1650 may generate subsystem-specific result set 1696, security-relevant subsystem 1652 may generate subsystem-specific result set 1698, and security-relevant subsystem 1654 may generate subsystem-specific result set 1700.

Threat mitigation process 10 may receive 1622 a plurality of subsystem-specific results sets (e.g., subsystem-specific result sets 1696, 1698, 1700) from the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654, respectively) that were generated in response to the plurality of subsystem-specific queries (e.g., subsystem-specific queries 1702, 1704, 1706).

Threat mitigation process 10 may normalize 1624 the plurality of subsystem-specific results sets (e.g., subsystem-specific result sets 1696, 1698, 1700) received from the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654, respectively) to define a unified result set (e.g., unified result set 1708). For example, threat mitigation process 10 may process the plurality of subsystem-specific results sets (e.g., subsystem-specific result sets 1696, 1698, 1700) so that the subsystem-specific results sets all have a common format, a common nomenclature, and/or a common structure.

Accordingly and when normalizing 1624 the plurality of subsystem-specific results sets (e.g., subsystem-specific result sets 1696, 1698, 1700) received from the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654, respectively) to define a unified result set (e.g., unified result set 1708), threat mitigation process 10 may translate 1626 a syntax of each of the plurality of subsystem-specific results sets (e.g., subsystem-specific result sets 1696, 1698, 1700) to a syntax of the unified result set (e.g., unified result set 1708).

As discussed above:

-   -   security-relevant subsystem 1650 may only be capable of         processing queries having a first structure and/or utilizing a         first nomenclature;     -   security-relevant subsystem 1652 may only be capable of         processing queries having a second structure and/or utilizing a         second nomenclature; and     -   security-relevant subsystem 1654 may only be capable of         processing queries having a third structure and/or utilizing a         third nomenclature.

Accordingly and when producing a result set:

-   -   security-relevant subsystem 1650 may only be capable producing a         result set (e.g., subsystem-specific result set 1696) having a         first structure and/or utilizing a first nomenclature;     -   security-relevant subsystem 1652 may only be capable producing a         result set (e.g., subsystem-specific result set 1698) having a         second structure and/or utilizing a second nomenclature; and     -   security-relevant subsystem 1654 may only be capable producing a         result set (e.g., subsystem-specific result set 1700) having a         third structure and/or utilizing a third nomenclature.

Accordingly and when normalizing 1624 the plurality of subsystem-specific results sets (e.g., subsystem-specific result sets 1696, 1698, 1700) received from the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654, respectively) to define a unified result set (e.g., unified result set 1708), threat mitigation process 10 may translate 1626 the syntax of:

-   -   subsystem-specific result set 1696 from a first structure/first         nomenclature to a unified syntax of the unified result set         (e.g., unified result set 1708);     -   subsystem-specific result set 1698 from a second         structure/second nomenclature to the unified syntax of the         unified result set (e.g., unified result set 1708);     -   subsystem-specific result set 1700 from a third structure/third         nomenclature to a unified syntax of the unified result set         (e.g., unified result set 1708).

Once normalized 1624, 1626, threat mitigation process 10 may combine the subsystem-specific results sets (e.g., subsystem-specific result sets 1696, 1698, 1700) to form the unified result set (e.g., unified result set 1708), wherein threat mitigation process 10 may then provide 1628 the unified result set (e.g., unified result set 1708) to a third-party (e.g., the user/owner/operator of computing platform 60).

Threat Hunting

Referring also to FIG. 33 , threat mitigation process 10 may establish 1800 connectivity with a plurality of security-relevant subsystems (e.g., security-relevant subsystems 226) within computing platform 60, wherein examples of security-relevant subsystems 226 may include but are not limited to: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems, Antivirus systems, operating systems, data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform.

When establishing 1800 connectivity with a plurality of security-relevant subsystems (e.g., security-relevant subsystems 226), threat mitigation process 10 may utilize at least one application program interface (e.g., API Gateway 224) to access at least one of the plurality of security-relevant subsystems. For example, a 1 API gateway may be utilized to access CDN (i.e., Content Delivery Network) system; a 2^(nd) API gateway may be utilized to access DAM (i.e., Database Activity Monitoring) system; a 3^(rd) API gateway may be utilized to access UBA (i.e., User Behavior Analytics) system; a 4^(th) API gateway may be utilized to access MDM (i.e., Mobile Device Management) system; a 5^(th) API gateway may be utilized to access IAM (i.e., Identity and Access Management) system; and a 6^(th) API gateway may be utilized to access DNS (i.e., Domain Name Server) system.

As discussed above, threat mitigation process 10 may allow a third-party (e.g., the user/owner/operator of computing platform 60) to define 1802 a unified query (e.g., query 1694) on a unified platform (e.g., unified platform 290) concerning security-relevant subsystems 226 (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654). In order to enable the querying of these separate and discrete subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654 within security-relevant subsystems 226) using a single query operation, threat mitigation process 10 may map (in the manner discussed above) one or more data fields of unified platform 290 (e.g., a platform effectuated by threat mitigation process 10) to one or more data fields of each of the plurality of security-relevant subsystems (e.g., e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654 within security-relevant subsystems 226).

Threat mitigation process 10 may denormalize 1804 the unified query (e.g., query 1694) to define a subsystem-specific query for each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654), thus defining a plurality of subsystem-specific queries (e.g., subsystem-specific queries 1702, 1704, 1706).

One or more of the plurality of subsystem-specific queries (e.g., subsystem-specific queries 1702, 1704, 1706) may have a defined execution schedule (e.g., defined execution schedule 1702S for subsystem-specific query 1702, defined execution schedule 1704S for subsystem-specific query 1704, and defined execution schedule 1706S for subsystem-specific query 1706). The defined execution schedule (e.g., defined execution schedule 1702S. 1704S, 1706S) may include one or more of: a defined execution time; a defined execution date; a defined execution frequency; and a defined execution scope.

-   -   Defined Execution Time: The defined execution schedule (e.g.,         defined execution schedule 1702S. 1704S, 1706S) may define a         particular time that a task is performed. For example, the         defined execution schedule (e.g., defined execution schedule         1702S. 1704S, 1706S) may define that an MDM (i.e., Mobile Device         Management) system provide a device access report at midnight         (local time) every day.     -   Defined Execution Date: The defined execution schedule (e.g.,         defined execution schedule 1702S. 1704S, 1706S) may define a         particular date that a task is performed. For example, the         defined execution schedule (e.g., defined execution schedule         1702S. 1704S, 1706S) may define that a router provide a port         opening report at COB every Friday (local time).     -   Defined Execution Frequency: The defined execution schedule         (e.g., defined execution schedule 1702S. 1704S, 1706S) may         define a particular frequency that a task is performed. For         example, the defined execution schedule (e.g., defined execution         schedule 1702S. 1704S, 1706S) may define that a CDN (i.e.,         Content Delivery Network) system provide a quantity delivered         report every hour.     -   Defined Execution Scope: The defined execution schedule (e.g.,         defined execution schedule 1702S. 1704S, 1706S) may define a         particular scope for a task being performed. For example, the         defined execution schedule (e.g., defined execution schedule         1702S. 1704S, 1706S) may define that a switch provide an         activity report for a specific port within the switch.

These defined execution schedules (e.g., defined execution schedule 1702S. 1704S, 1706S) may be a default execution schedule that is configured to be revisable by a third-party (e.g., the user/owner/operator of computing platform 60). For example and with respect to these defined execution schedules (e.g., defined execution schedule 1702S, 1704S, 1706S):

-   -   the default time may be midnight, which may be revisable by the         third-party (e.g., the user/owner/operator of computing platform         60);     -   the default date may be the 1^(st) of the month, which may be         revisable by the third-party (e.g., the user/owner/operator of         computing platform 60);     -   the default frequency may be once, which may be revisable by the         third-party (e.g., the user/owner/operator of computing platform         60); and     -   the default scope may be a narrower scope, which may be         revisable by the third-party (e.g., the user/owner/operator of         computing platform 60).

As discussed above, unified platform 290 (e.g., a platform effectuated by threat mitigation process 10) is shown to include four data fields (e.g., data fields 1686, 1688, 1690, 1692), wherein a third-party (e.g., the user/owner/operator of computing platform 60) may utilize these data fields to define the unified query (e.g., query 1694). As this unified query (e.g., query 1694) may be used as the basis to search for pertinent information on (in this example) three entirely separate and discrete subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654), it is foreseeable that these subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654) may require queries to be structured differently.

Accordingly and when denormalizing 1804 the unified query (e.g., query 1694) to define a subsystem-specific query for each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654), thus defining a plurality of subsystem-specific queries (e.g., subsystem-specific queries 1702, 1704, 1706), threat mitigation process 10 may translate 1806 a syntax of the unified query (e.g., query 1694) to a syntax of each of the plurality of subsystem-specific queries (e.g., subsystem-specific queries 1702, 1704, 1706). For example:

-   -   security-relevant subsystem 1650 may only be capable of         processing queries having a first structure and/or utilizing a         first nomenclature;     -   security-relevant subsystem 1652 may only be capable of         processing queries having a second structure and/or utilizing a         second nomenclature; and     -   security-relevant subsystem 1654 may only be capable of         processing queries having a third structure and/or utilizing a         third nomenclature.

Accordingly and when denormalizing 1804 the unified query (e.g., query 1694) to define a plurality of subsystem-specific queries (e.g., subsystem-specific queries 1702, 1704, 1706), threat mitigation process 10 may translate 1806 the syntax of the unified query (e.g., query 1694) so that:

-   -   a subsystem-specific query 1702 has a first structure and/or         utilizes a first nomenclature;     -   subsystem-specific query 1704 has a second structure and/or         utilizes a second nomenclature;     -   subsystem-specific query 1706 has a third structure and/or         utilizes a third nomenclature.

Threat mitigation process 10 may provide 1808 the plurality of subsystem-specific queries (e.g., subsystem-specific queries 1702, 1704, 1706) to the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654).

The plurality of subsystem-specific queries (e.g., subsystem-specific queries 1702, 1704, 1706) may be effectuated on the appropriate security-relevant subsystem. For example, subsystem-specific query 1702 may be effectuated on security-relevant subsystem 1650, subsystem-specific query 1704 may be effectuated on security-relevant subsystem 1652, and subsystem-specific query 1706 may be effectuated on security-relevant subsystem 1654; resulting in the generation of subsystem-specific result sets. For example, security-relevant subsystem 1650 may generate subsystem-specific result set 1696, security-relevant subsystem 1652 may generate subsystem-specific result set 1698, and security-relevant subsystem 1654 may generate subsystem-specific result set 1700.

Threat mitigation process 10 may receive 1810 a plurality of subsystem-specific results sets (e.g., subsystem-specific result sets 1696, 1698, 1700) from the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654, respectively) that were generated in response to the plurality of subsystem-specific queries (e.g., subsystem-specific queries 1702, 1704, 1706).

And by mapping (in the manner discussed above) one or more data fields within a result set structure of each of the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654) to one or more data fields within a result set structure of the unified platform (e.g., unified platform 290), these subsystem-specific result sets (e.g., subsystem-specific result sets 1696, 1698, 1700) may be provided to the unified platform (e.g., unified platform 290) in a fashion that enables the unified platform (e.g., unified platform 290) to properly process these subsystem-specific result sets (e.g., subsystem-specific result sets 1696, 1698, 1700).

Threat mitigation process 10 may normalize 1812 the plurality of subsystem-specific results sets (e.g., subsystem-specific result sets 1696, 1698, 1700) received from the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654, respectively) to define a unified result set (e.g., unified result set 1708). For example, threat mitigation process 10 may process the plurality of subsystem-specific results sets (e.g., subsystem-specific result sets 1696, 1698, 1700) so that the subsystem-specific results sets all have a common format, a common nomenclature, and/or a common structure.

Accordingly and when normalizing 1812 the plurality of subsystem-specific results sets (e.g., subsystem-specific result sets 1696, 1698, 1700) received from the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654, respectively) to define a unified result set (e.g., unified result set 1708), threat mitigation process 10 may translate 1814 a syntax of each of the plurality of subsystem-specific results sets (e.g., subsystem-specific result sets 1696, 1698, 1700) to a syntax of the unified result set (e.g., unified result set 1708).

As discussed above:

-   -   security-relevant subsystem 1650 may only be capable of         processing queries having a first structure and/or utilizing a         first nomenclature;     -   security-relevant subsystem 1652 may only be capable of         processing queries having a second structure and/or utilizing a         second nomenclature; and     -   security-relevant subsystem 1654 may only be capable of         processing queries having a third structure and/or utilizing a         third nomenclature.

Accordingly and when producing a result set.

-   -   security-relevant subsystem 1650 may only be capable producing a         result set (e.g., subsystem-specific result set 1696) having a         first structure and/or utilizing a first nomenclature;     -   security-relevant subsystem 1652 may only be capable producing a         result set (e.g., subsystem-specific result set 1698) having a         second structure and/or utilizing a second nomenclature; and     -   security-relevant subsystem 1654 may only be capable producing a         result set (e.g., subsystem-specific result set 1700) having a         third structure and/or utilizing a third nomenclature.

Accordingly and when normalizing 1812 the plurality of subsystem-specific results sets (e.g., subsystem-specific result sets 1696, 1698, 1700) received from the plurality of security-relevant subsystems (e.g., security-relevant subsystem 1650, security-relevant subsystem 1652 and security-relevant subsystem 1654, respectively) to define a unified result set (e.g., unified result set 1708), threat mitigation process 10 may translate 1814 the syntax of:

-   -   subsystem-specific result set 1696 from a first structure/first         nomenclature to a unified syntax of the unified result set         (e.g., unified result set 1708);     -   subsystem-specific result set 1698 from a second         structure/second nomenclature to the unified syntax of the         unified result set (e.g., unified result set 1708);     -   subsystem-specific result set 1700 from a third structure/third         nomenclature to a unified syntax of the unified result set         (e.g., unified result set 1708).

As could be imagined, it is foreseeable that e.g., one or more of security-relevant subsystems 226 may be offline when asked to perform a task (or go offline while performing a task). Therefore, one or more of subsystem-specific result sets 1696, 1698, 1700 may be missing/incomplete/defective. Accordingly, threat mitigation process 10 may be configured to determine 1816 whether one or more of the plurality of subsystem-specific queries (e.g., subsystem-specific queries 1702, 1704, 1706) failed to execute properly, thus defining one or more failed subsystem-specific queries. And if one or more of the plurality of subsystem-specific queries (e.g., subsystem-specific queries 1702, 1704, 1706) failed to execute properly, threat mitigation process 10 may reexecute 1818 the one or more failed subsystem-specific queries.

As discussed above and in this example, threat mitigation process 10 provides 1808 subsystem-specific query 1702 to security-relevant subsystem 1650; subsystem-specific query 1704 to security-relevant subsystem 1652; and subsystem-specific query 1706 to security-relevant subsystem 1654.

Assume for this example that security-relevant subsystem 1650 went offline while executing subsystem-specific query 1702 and has since come back online. However, upon threat mitigation process 10 examining subsystem-specific result set 1696, it is determined that subsystem-specific result set 1696 only contains 53,246 pieces of data (but is supposed to contain 100,000 pieces of data). Accordingly, threat mitigation process 10 may determine 1816 that subsystem-specific query 1702 failed to execute properly, thus defining subsystem-specific query 1702 as a failed subsystem-specific query. Accordingly, threat mitigation process 10 may reexecute 1818 the failed subsystem-specific query (e.g., subsystem-specific query 1702) so the requested 100,000 pieces of data may be obtained from security-relevant subsystem 1650 (and the previously-obtained 53,246 pieces of data may be deleted).

Once the plurality of subsystem-specific results sets (e.g., subsystem-specific result sets 1696, 1698, 1700) are normalized 1812, threat mitigation process 10 may combine the subsystem-specific results sets (e.g., subsystem-specific result sets 1696, 1698, 1700) to form the unified result set (e.g., unified result set 1708), wherein threat mitigation process 10 may then provide 1820 the unified result set (e.g., unified result set 1708) to a third-party (e.g., the user/owner/operator of computing platform 60).

Project Orion

As discussed above, threat mitigation process 10 may be configured to enable the querying of multiple separate and discrete subsystems (e.g., security-relevant subsystems 226) using a single query operation. Further and as discussed above, since security-relevant subsystems 226 may monitor and log activity with respect to computing platform 60 and computing platform 60 may include a wide range of computing devices (e.g., server computers 200, 202, desktop computer 204, laptop computer 206, network 208, web application firewall 212, wireless access point 214, switch 216, router 218, gateway 220, NAS 222, and API Gateway 224), threat mitigation process 10 may provide holistic monitoring of the entirety of computing platform 60 (e.g., both central devices and end point devices), thus providing what is generally referred to as XDR (extended detection and response) functionality. As defined by analyst firm Gartner, Extended Detection and Response (XDR) is “a SaaS-based, vendor-specific, security threat detection and incident response tool that natively integrates multiple security products into a cohesive security operations system that unifies all licensed components.”

As also discussed above, threat mitigation process 10 may monitor computing platform 60 for the occurrence of a security event and (in the event of such an occurrence) may gather artifacts concerning the same. In order to effectuate the same, threat mitigation process 10 may deploy generic or custom detection rules (e.g., detection rules 292), such as logic specific to both central devices and end point devices (e.g., server computers 200, 202, desktop computer 204, laptop computer 206, network 208, web application firewall 212, wireless access point 214, switch 216, router 218, gateway 220, NAS 222, and API Gateway 224). These generic or custom detection rules (e.g., detection rules 292) may detect when malicious activity occurs in customer environments (e.g., computing platform 60).

These generic or custom detection rules (e.g., detection rules 292) may be manually deployed in customer environments (e.g., computing platform 60) via e.g., SIEM system 230 and/or central devices/end point devices (e.g., server computers 200, 202, desktop computer 204, laptop computer 206, network 208, web application firewall 212, wireless access point 214, switch 216, router 218, gateway 220, NAS 222, and API Gateway 224), wherein these detection rules (e.g., detection rules 292) may be manually tuned for each piece of customer technology (e.g., server computers 200, 202, desktop computer 204, laptop computer 206, network 208, web application firewall 212, wireless access point 214, switch 216, router 218, gateway 220, NAS 222, and API Gateway 224). When these detection rules are manually configured, changing/implementing new detection rules within e.g., computing platform 60 may prove costly/time consuming/difficult for the administrators of threat mitigation process 10.

These generic or custom detection rules (e.g., detection rules 292) executed on the customer technology (e.g., server computers 200, 202, desktop computer 204, laptop computer 206, network 208, web application firewall 212, wireless access point 214, switch 216, router 218, gateway 220, NAS 222, and API Gateway 224) may detect security events (e.g., DDoS events, DoS events, phishing events, spamming events, malware events, web attacks, and exploitation events), which may result in the generation of alerts (e.g., detection events 294) that are provided to one of more analysts (e.g., analyst 256) of threat mitigation process 10.

These alerts (e.g., detection events 294) may generate entries in the customer technology (e.g., server computers 200, 202, desktop computer 204, laptop computer 206, network 208, web application firewall 212, wireless access point 214, switch 216, router 218, gateway 220, NAS 222, and API Gateway 224), which may be collected by and/or provided to threat mitigation process 10. Unfortunately, a large quantity of alerts (e.g., detection events 294) may overwhelm the analysts (e.g., analyst 256) of threat mitigation process 10, resulting in the inefficient operation/performance of threat mitigation process 10.

As will be discussed below in greater detail, threat mitigation process 10 may be configured to enhance performance and efficiency via automation and/or artificial intelligence, wherein these enhancements may occur in the following phases:

-   -   In Phase 1, threat mitigation process 10 may be configured to         group detection events (e.g., detection events 294) from a         single piece of technology (e.g., a central device or an end         point device) if those detection events are related. These         detection events (e.g., detection events 294) may be detected         via detection rules (e.g., detection rules 292) defined and         executed on the piece of technology (e.g., a central device or         an end point device). Once grouped, this group of detection         events (e.g., detection events 294) may be considered a single         security incident.     -   In Phase 2, threat mitigation process 10 may be configured to         group detection events (e.g., detection events 294) from         multiple pieces of technology (e.g., central devices and/or end         point devices) if those detection events are related. These         detection events (e.g., detection events 294) may be detected         via detection rules (e.g., detection rules 292) defined and         executed on the pieces of technology (e.g., central devices         and/or end point devices). Once grouped, this group of detection         events (e.g., detection events 294) may be considered a single         security incident.     -   In Phase 3, the detection events (e.g., detection events 294)         are not detected via detection rules (e.g., detection rules 292)         defined and executed on the pieces of technology (e.g., central         devices and/or end point devices). Specifically, threat         mitigation process 10 may be configured to directly detect such         detection events (e.g., detection events 294) by executing         queries on the pieces of technology (e.g., central devices         and/or end point devices).     -   In Phase 4, threat mitigation process 10 may be configured to         enable a user of threat mitigation process 10 to define a         universal detection rule (e.g., universal detection rule 296) in         a common language for e.g., computing platform 60. Threat         mitigation process 10 may then translate this universal         detection rule (e.g., universal detection rule 296) into a         plurality of technology-specific detection rules (e.g.,         detection rules 292) that are executable on the discrete pieces         of customer technology (e.g., server computers 200, 202, desktop         computer 204, laptop computer 206, network 208, web application         firewall 212, wireless access point 214, switch 216, router 218,         gateway 220, NAS 222, and API Gateway 224).     -   In Phase 5, threat mitigation process 10 may be configured to         utilize machine learning/artificial intelligence to analyze         e.g., current detection rules (e.g., detection rules 292) and         historical data concerning previous security events (e.g., DDoS         events, DoS events, phishing events, spamming events, malware         events, web attacks, and exploitation events) so that new         detection rules may be automatically generated and/or executed         by threat mitigation process 10). Accordingly and in such a         configuration, security events (e.g., DDoS events, DoS events,         phishing events, spamming events, malware events, web attacks,         and exploitation events) may be automatically detected and         detection rules (e.g., detection rules 292) may be automatically         generated based upon these automatically detected security         events.     -   In Phase 6, threat mitigation process 10 may be configured to         store data concerning computing platform 60, the customer         technology contained therein (e.g., server computers 200, 202,         desktop computer 204, laptop computer 206, network 208, web         application firewall 212, wireless access point 214, switch 216,         router 218, gateway 220, NAS 222, and API Gateway 224), and the         security events occurring therein (e.g., DDoS events, DoS         events, phishing events, spamming events, malware events, web         attacks, and exploitation events). Threat mitigation process 10         may further be configured to present such data in a fashion that         identifies relationships between the entities within the data,         as opposed to the data associated with the entities themselves.

Accordingly and as discussed above, threat mitigation process 10 may be configured to centralize the querying of the customer technology (e.g., server computers 200, 202, desktop computer 204, laptop computer 206, network 208, web application firewall 212, wireless access point 214, switch 216, router 218, gateway 220, NAS 222, and API Gateway 224), thus eliminating the need for locally-executed detection rules. Accordingly and when configured in such a fashion, threat mitigation process 10 may eliminate the need for SIEM system 230, as threat mitigation process 10 may gather the security event information directly.

Specifically, threat mitigation process 10 may enable the definition of universal rules (e.g., universal rule 296) in a common language that may be translated into a plurality of technology-specific rules (e.g., one or more of detection rules 292) that are executable on the discrete pieces of customer technology (e.g., server computers 200, 202, desktop computer 204, laptop computer 206, network 208, web application firewall 212, wireless access point 214, switch 216, router 218, gateway 220, NAS 222, and API Gateway 224). Accordingly and through the use of such technology-specific rules (e.g., one or more of detection rules 292), threat mitigation process 10 may directly execute queries on the pieces of customer technology (e.g., central devices and/or end point devices), thus enabling the direct detection of security events on the customer technology (e.g., central devices and/or end point devices) and eliminating the need for SIEM system 230.

The six phases of threat mitigation process 10 summarized above are discussed below in greater detail.

PHASE 1: As discussed above, threat mitigation process 10 may be configured to group detection events (e.g., detection events 294) from a single piece of technology (e.g., a central device or an end point device) if those detection events are related. These detection events (e.g., detection events 294) may be detected via detection rules (e.g., detection rules 292) defined and executed on the piece of customer technology (e.g., a central device or an end point device). Once grouped, this group of detection events (e.g., detection events 294) may be considered a single security incident.

Specifically:

-   -   Threat mitigation process 10 may be configured to define a         specific method for retrieving detection events (e.g., detection         events 294) of security events (e.g., DDoS events, DoS events,         phishing events, spamming events, malware events, web attacks,         and exploitation events) from differing pieces of customer         technology (e.g., central devices and/or end point devices).     -   Threat mitigation process 10 may be configured to define a         service to manage and schedule the retrieving of these detection         events (e.g., detection events 294), wherein the data within         these detection events (e.g., detection events 294) may be         normalized into a common ontology.     -   Each of these detection events (e.g., detection events 294) may         have one or more “artifacts” associated with them, wherein these         artifacts may include but are not limited to IP addresses, file         names, user name, host names, file hashes, etc.     -   Threat mitigation process 10 may be configured to store these         detection events (e.g., detection events 294) within a datastore         (e.g., a data lake). Threat mitigation process 10 may process         these detection events (e.g., detection events 294) from the         datastore (e.g., a data lake) to decide what detection events         should be grouped into a security incident. A security incident         is one or more detection events (e.g., detection events 294)         bound together based upon common artifacts and/or other         attributes that represent a single malicious action or actor.     -   Threat mitigation process 10 may be configured to map each         detection event (e.g., detection events 294) retrieved from the         customer technology (e.g., a central device or an end point         device) to a security incident, wherein these detection events         may be processed accordingly.     -   Any grouping of detection events (e.g., detection events 294)         within this phase may be more rudimentary, as threat mitigation         process 10 may only group detection events (e.g., detection         events 294) that occur on a single piece of customer technology         (e.g., a central device or an end point device).     -   For example, assume that a user within computing platform 60 is         running Windows PowerShell on Host A in an abnormal way . . .         and that is noted by a detection rule running on Host A. If this         PowerShell abnormality occurs four more times on Host A, the         detection rule running on Host A will note it each of those four         additional times.     -   Threat mitigation process 10 may group these five discrete         detection events (e.g., detection events 294) into a single         security incident, as these five discrete detection events         (e.g., detection events 294) are very similar in nature and all         occurred on Host A.     -   The rules concerning how these five discrete detection events         (e.g., detection events 294) may be grouped into a single         security incident may be manually generated by e.g., an         administrator of threat mitigation process 10.     -   These five discrete detection events (e.g., detection events         294) may have overlapping artifacts (e.g., all Windows         PowerShell attacks) and differing artifacts (e.g., different         command lines). By combining these five discrete detection         events (e.g., detection events 294) under the umbrella of one         security incident, all artifacts (both the overlapping and the         differing artifacts) may be combined to provide a clearer         picture of the security incident for e.g., analyst 256.     -   The detection events (e.g., detection events 294) that are         occurring (in this example) on Host A may be generated via         detection rules (e.g., detection rules 292) native to (or         defined by) Host A or via detection rules (e.g., detection rules         292) defined by threat mitigation process 10.     -   As new detection events occur, threat mitigation process 10 may         be configured to process each new detection event to determine         if the new detection event is part of (i.e., associated with) a         previously-defined security incident. When making such a         determination, threat mitigation process 10 may utilize logical         rules and/or determine the amount of time that has passed since         the last detection event in the security incident.     -   In the event that a new detection event is associated with a         previously-defined security incident, threat mitigation process         10 may update the previously-defined security incident to         include the new detection event and any new artifacts associated         therewith, thus allowing for a more thorough and up-to-date         processing of the security event by e.g., analyst 256.

As will be discussed below in greater detail, threat mitigation process 10 may be configured to receive detection events (e.g., detection events 294) for security events that occur on a single piece of customer technology (e.g., a central device or an end point device) so that they may be grouped into a single security incident to enable easier analysis by analyst 256.

For example and referring also to FIG. 34 , threat mitigation process 10 may receive 1900 a plurality of detection events (e.g., detection events 294) concerning a plurality of security events occurring on a security-relevant subsystem (e.g., security-relevant subsystems 226) within a computing platform (e.g., computing platform 60).

The plurality of security events may be detected on the security-relevant subsystem (e.g., security-relevant subsystems 226) using one or more detection rules (e.g., detection rules 292) executed on the security-relevant subsystem (e.g., security-relevant subsystems 226). As discussed above, threat mitigation process 10 may deploy generic or custom detection rules (e.g., detection rules 292), such as logic specific to both central devices and end point devices (e.g., server computers 200, 202, desktop computer 204, laptop computer 206, network 208, web application firewall 212, wireless access point 214, switch 216, router 218, gateway 220, NAS 222, and API Gateway 224). These generic or custom detection rules (e.g., detection rules 292) may detect when malicious activity occurs in customer environments (e.g., computing platform 60).

As would be expected, the language/nomenclature/structure of such detection events (e.g., detection events 294) may vary, as they are obtained from different security-relevant subsystem (e.g., security-relevant subsystems 226). Accordingly, threat mitigation process 10 may normalize 1902 the plurality of detection events (e.g., detection events 294) into a common ontology. For example and when normalizing 1902 the plurality of detection events (e.g., detection events 294) into a common ontology, threat mitigation process 10 may translate 1904 a syntax of each of the plurality of detection events (e.g., detection events 294) into a common syntax.

Examples of the plurality of security events may include but are not limited to one or more of:

-   -   Denial of Service (DoS)/Distributed Denial of Service DDoS         Events: A DOS (Denial of Service) attack is a type of         cyber-attack in which a perpetrator tries to make a website or         online service unavailable to its users by overwhelming it with         traffic or other malicious activities. The attacker achieves         this by flooding the target system with a large number of         requests or data packets, which can cause the system to slow         down, crash, or become unavailable to legitimate users. In some         cases, the attacker may use multiple computers or devices to         launch a coordinated attack, known as a Distributed Denial of         Service (DDoS) attack, which can make it even more difficult to         block the attack and restore service. DOS attacks can have a         serious impact on businesses and organizations that rely on         their online presence to operate, causing financial losses,         damage to reputation, and even legal consequences in some cases.     -   Man-in-the-Middle (MitM) Events: A Man-in-the-Middle (MITM)         attack is a type of cyber-attack where an attacker intercepts         and alters communication between two parties who believe they         are communicating directly with each other. The attacker sits in         between the two parties and can intercept, modify, or inject         data without either party being aware of it. In a typical MITM         attack scenario, the attacker can eavesdrop on the communication         between the two parties, steal sensitive information such as         passwords, credit card numbers, or personal data, or modify the         communication to manipulate the parties' actions or decisions.         MITM attacks can occur in various ways, including exploiting         vulnerabilities in wireless networks, using phishing emails to         trick users into visiting fake websites, or compromising network         routers or switches.     -   Phishing Events: Phishing is a type of cyber-attack that targets         individuals or organizations with the goal of stealing sensitive         information, such as login credentials, credit card numbers, or         personal data. Phishing attacks typically involve sending an         email or message that appears to be from a legitimate source,         such as a bank, social media site, or e-commerce website, but is         actually a fake or spoofed message designed to trick the         recipient into clicking on a malicious link, downloading         malware, or entering their personal information. Once the         recipient falls for the phishing attack and clicks on the link         or enters their credentials, the attacker can use the stolen         information to commit fraud or gain unauthorized access to         sensitive data or systems. Phishing attacks can be highly         effective because they often rely on social engineering         techniques that exploit people's trust and fear. Phishing emails         can be highly personalized and may include convincing logos or         graphics that make them look like legitimate messages.     -   Password Attack Events. A password attack is a type of         cyber-attack that attempts to guess or crack a user's password         to gain unauthorized access to their accounts or systems.         Password attacks can take various forms, including:         -   i. Brute-force attacks: In this type of attack, the attacker             systematically tries every possible combination of             characters to guess the user's password. This is usually             done using automated software tools that can try thousands             or even millions of password combinations in a short time.         -   ii. Dictionary attacks: A dictionary attack is similar to a             brute-force attack but uses a predefined list of words or             phrases commonly used as passwords. The attacker can also             add variations to the words or try different combinations to             increase the likelihood of success.         -   iii. Social engineering attacks: This type of attack             involves tricking the user into revealing their password             through manipulation or deception. The attacker may use             phishing emails or phone calls to gather information or use             psychological tactics to gain the user's trust and obtain             their password.     -   SQL Injection Events: An SQL (Structured Query Language)         injection attack is a type of cyber-attack that targets         databases or web applications that use SQL to process user         inputs. The attack involves inserting malicious SQL code into an         application's input field, which is then executed by the         application's database server, potentially allowing the attacker         to access, modify, or delete sensitive data. SQL injection         attacks can be highly effective because many web applications         and databases don't properly validate user inputs or use         prepared statements, making them vulnerable to manipulation.         Attackers can exploit this vulnerability by using SQL commands         such as SELECT, UPDATE, DELETE, or DROP to bypass         authentication, gain unauthorized access, or steal sensitive         data.     -   Cross-Site Scripting (XSS) Events: Cross-site scripting (XSS) is         a type of cyber-attack that targets web applications by         injecting malicious code into a website or web application that         is then executed by users who access the website. The attacker         can use this technique to steal sensitive data, such as login         credentials or credit card information, or to perform other         malicious actions, such as redirecting users to a phishing site         or spreading malware. XSS attacks can occur when an attacker is         able to inject malicious code into a web application or website,         often by exploiting vulnerabilities in input fields, such as         search boxes or comment forms. When a user visits the website or         web application, the malicious code is executed in their         browser, giving the attacker access to sensitive information or         the ability to manipulate the user's session. There are several         types of XSS attacks, including:         -   i. Stored XSS: The attacker injects malicious code into a             web application, which is then stored on the server and             executed every time a user accesses the affected page.         -   ii. Reflected XSS: The attacker injects malicious code into             a website or web application that is then reflected back to             the user's browser, often through a search query or URL             parameter.         -   iii. DOM-based XSS: The attacker injects malicious code into             a website or web application that is then executed by             modifying the Document Object Model (DOM) in the user's             browser.     -   Insider Threat Events: Insider threat events are a type of         cyber-attack that occur when an individual with authorized         access to an organization's systems or data intentionally or         unintentionally causes harm to the organization. Insider threat         events can include theft of sensitive information, unauthorized         access, sabotage, or accidental damage caused by employee error         or negligence. There are several types of insider threat events,         including:         -   i. Malicious insiders: These are employees or contractors             who intentionally cause harm to the organization, often for             financial gain or personal reasons. They may steal sensitive             data, install malware, or damage the organization's systems.         -   ii. Careless insiders: These are employees or contractors             who inadvertently cause harm to the organization due to             negligence or lack of security awareness. For example, they             may click on a phishing email, use weak passwords, or             inadvertently expose sensitive data.         -   iii. Compromised insiders: These are employees or             contractors whose accounts have been compromised by an             external attacker, allowing the attacker to gain access to             sensitive data or systems.     -   Spamming Events: Spamming attacks are a type of cyber-attack         that involve the sending of unsolicited messages or emails,         often for the purpose of spreading malware, phishing for         sensitive information, or advertising products or services.         Spamming attacks can be carried out through various methods,         including email, text messaging, social media, and online         forums. Spamming attacks can be highly effective because they         can be targeted to specific individuals or groups, and often use         tactics to evade detection by spam filters or other security         measures. Attackers may use social engineering techniques, such         as posing as a legitimate organization or using a convincing         subject line, to trick users into opening the message or         clicking on a link.     -   Malware Events: Malware attacks are a type of cyber-attack that         involve the distribution of malicious software designed to         disrupt, damage, or gain unauthorized access to a computer         system or network. Malware can take many forms, including         viruses, worms, Trojan horses, ransomware, spyware, and adware.         Malware attacks can be initiated through various methods,         including email attachments, downloads from infected websites,         social engineering, or exploiting vulnerabilities in software or         operating systems. Once the malware is installed on a system, it         can perform a range of malicious activities, such as stealing         sensitive data, hijacking system resources, or encrypting files         and demanding ransom payment.     -   Web Attacks Events: Web attacks are a type of cyber-attack that         target web-based applications, servers, or databases. Web         attacks can take many forms and are often used to gain         unauthorized access to sensitive information or systems, steal         data, or compromise website functionality. Some common web         attacks include:         -   i. Cross-Site Scripting (XSS): An attacker injects malicious             code into a web page, which is then executed by a victim's             browser when they view the page. This can be used to steal             sensitive information, such as login credentials, or to             perform other malicious actions on the victim's behalf.         -   ii. SQL injection: An attacker inserts malicious SQL code             into a web application's input fields, which is then             executed by the application's database. This can be used to             extract sensitive data or to gain unauthorized access to the             application's backend systems.         -   iii. Cross-Site Request Forgery (CSRF): An attacker tricks a             victim into performing an action on a web application             without their knowledge or consent. This can be used to             perform actions on the victim's behalf, such as making             unauthorized purchases or changing their account             information.         -   iv. Distributed Denial of Service (DDoS): An attacker floods             a web server with a large volume of requests, overwhelming             its resources and causing it to become unavailable to             legitimate users.     -   Exploitation Events: An exploitation attack is a type of         cyber-attack that involves the exploitation of a vulnerability         or weakness in a computer system, application, or network in         order to gain unauthorized access, steal data, or execute         malicious code. Exploitation attacks can take many forms,         including buffer overflows, SQL injections, and zero-day         attacks, and are often used in combination with other types of         attacks, such as social engineering or phishing attacks, to         increase their effectiveness.

Examples of the security-relevant subsystem (e.g., security-relevant subsystems 226) may include but are not limited to one or more of:

-   -   CDN (i.e., Content Delivery Network) systems;     -   DAM (i.e., Database Activity Monitoring) systems;     -   UBA (i.e., User Behavior Analytics) systems;     -   MDM (i.e., Mobile Device Management) systems;     -   IAM (i.e., Identity and Access Management) systems;     -   DNS (i.e., Domain Name Server) systems;     -   Antivirus systems;     -   operating systems;     -   data lakes;     -   data logs;     -   security-relevant software applications;     -   security-relevant hardware systems; and     -   resources external to the computing platform (e.g., computing         platform 60).

Threat mitigation process 10 may identify 1906 two or more associated detection events (e.g., two or more of detection events 294) included within the plurality of detection events (e.g., detection events 294) and may group 1908 the two or more associated detection events (e.g., two or more of detection events 294) to define a security incident (e.g., a group of related detection events), which may be provided to one of more analysts (e.g., analyst 256) of threat mitigation process 10.

Additionally, one or more artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226) may be associated with each of the plurality of detection events (e.g., detection events 294). Examples of such artifacts/log entries may include but are not limited to: IP addresses, file names, user names, host names, file hashes, port IDs, etc.

Accordingly and when identifying 1906 two or more associated detection events (e.g., detection events 294) included within the plurality of detection events (e.g., detection events 294), threat mitigation process 10 may identify 1910 two or more detection events (e.g., detection events 294) included within the plurality of detection events (e.g., detection events 294) that have common artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226).

Further and when grouping 1908 the two or more associated detection events (e.g., detection events 294) into a security incident (e.g., a group of related detection events), threat mitigation process 10 may group 1912 the one or more artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226) associated with each of the two or more associated detection events (e.g., detection events 294) to form an artifact/log entry set for the security incident (e.g., a group of related detection events), which are provided to one of more analysts (e.g., analyst 256) of threat mitigation process 10.

As would be expected and over time, threat mitigation process 10 may receive 1914 one or more additional detection events (e.g., one or more of detection events 294) concerning one or more additional security events occurring on the security-relevant subsystem (e.g., security-relevant subsystems 226) within the computing platform (e.g., computing platform 60). Accordingly, threat mitigation process 10 may add 1916 the one or more additional detection events (e.g., one or more of detection events 294) to the security incident (e.g., the above-described group of related detection events) if the one or more additional detection events (e.g., one or more of detection events 294) are related to the two or more associated detection events (e.g., two or more of detection events 294).

PHASE 2: As discussed above, threat mitigation process 10 may be configured to group detection events (e.g., detection events 294) from multiple pieces of technology (e.g., central devices and/or end point devices) if those detection events are related. These detection events (e.g., detection events 294) may be detected via detection rules (e.g., detection rules 292) defined and executed on the pieces of technology (e.g., central devices and/or end point devices). Once grouped, this group of detection events (e.g., detection events 294) may be considered a single security incident.

Specifically:

-   -   Threat mitigation process 10 may be configured to allow         detection rules (e.g., detection rules 292) from disparate         customer technologies (e.g., a central device and an end point         device) to be combined to trigger a security incident.     -   Any grouping of detection events (e.g., detection events 294)         within this phase may be more complex, as it may group detection         events (e.g., detection events 294) that occur across multiple         pieces of customer technology (e.g., a central device and an end         point device).     -   As discussed above, assume that a user within computing platform         60 is running Windows PowerShell on Host A in an abnormal way .         . . and that is noted by a detection rule running on Host A. If         this PowerShell abnormality occurs four more times on Host A,         the detection rule running on Host A will note it each of those         four additional times. Further, suppose that in addition to the         five Windows PowerShell events, an IDS alert on network (that         concerns the IP address of Host A) and a suspicious email to         User X (who uses Host A) also occurs.     -   Accordingly, threat mitigation process 10 may group all seven of         these detection events (e.g., detection events 294) together         under the umbrella of a single security incident due to their         commonality, even though the seven detection events span three         technologies.     -   Therefore, threat mitigation process 10 may treat all seven of         these detection events (e.g., detection events 294) as being         part of one incident. wherein some of the detection events may         have overlapping artifacts (e.g., Windows PowerShell attacks)         and differing artifacts (e.g., network attack, email attack). By         combining these seven (five old plus two new) discrete         detections events (e.g., detection events 294) under the         umbrella of one security incident, all artifacts (both the         overlapping and the differing artifacts) may be combined to         provide a clearer picture of the security incident for e.g.,         analyst 256.     -   The rules concerning how these seven discrete detection events         (e.g., detection events 294) may be grouped into a single         security incident may be manually generated by e.g., an         administrator of threat mitigation process 10.     -   The detection events (e.g., detection events 294) that are         occurring (in this example) on multiple hosts may be generated         via detection rules (e.g., detection rules 292) native to (or         defined by) these hosts or via detection rules (e.g., detection         rules 292) defined by threat mitigation process 10.     -   As new detection events occur, threat mitigation process 10 may         be configured to process each new detection event to determine         if the new detection event is part of (i.e., associated with) a         previously-defined security incident. When making such a         determination, threat mitigation process 10 may utilize logical         rules and/or determine the amount of time that has passed since         the last detection event in the security incident.     -   In the event that a new detection event is associated with a         previously-defined security incident, threat mitigation process         10 may update the previously-defined security incident to         include the new detection event and any new artifacts associated         therewith, thus allowing for a more thorough and up-to-date         processing of the security event by e.g., analyst 256.

As will be discussed below in greater detail, threat mitigation process 10 may be configured to receive detection events (e.g., detection events 294) for security events that occur on multiple pieces of customer technology (e.g., a central device or an end point device) so that they may be grouped into a single security incident to enable easier analysis by analyst 256.

For example and referring also to FIG. 35 , threat mitigation process 10 may receive 2000 a plurality of events (e.g., detection events 294) concerning a plurality of security events occurring on two or more security-relevant subsystems (e.g., security-relevant subsystems 226) within a computing platform (e.g., computing platform 60).

As discussed above, the plurality of security events may be detected on the plurality of security-relevant subsystem (e.g., security-relevant subsystems 226) using one or more detection rules executed on the plurality of security-relevant subsystem (e.g., security-relevant subsystems 226).

As discussed above, the language/nomenclature/structure of such detection events (e.g., detection events 294) may vary, as they are obtained from different security-relevant subsystem (e.g., security-relevant subsystems 226). Accordingly, threat mitigation process 10 may normalize 2002 the plurality of detection events (e.g., detection events 294) into a common ontology. For example and when normalizing 2002 the plurality of detection events (e.g., detection events 294) into a common ontology, threat mitigation process 10 may translate 2004 a syntax of each of the plurality of detection events (e.g., detection events 294) into a common syntax.

As discussed above, the plurality of security events may include one or more of: Denial of Service (DoS) events; Distributed Denial of Service DDoS events; Man-in-the-Middle (MitM) events; phishing events; Password Attack events; SQL Injection events; Cross-Site Scripting (XSS) events; Insider Threat events; spamming events; malware events; web attacks; and exploitation events.

As discussed above, examples of the security-relevant subsystem (e.g., security-relevant subsystems 226) may include one or more of: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems; Antivirus systems; operating systems; data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform (e.g., computing platform 60).

Threat mitigation process 10 may identify 2006 two or more associated detection events (e.g., two or more of detection events 294) included within the plurality of detection events (e.g., detection events 294) and may group 2008 the two or more associated detection events (e.g., detection events 294) to define a security incident (e.g., a group of related detection events), which may be provided to one of more analysts (e.g., analyst 256) of threat mitigation process 10.

Additionally, one or more artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226) may be associated with each of the plurality of detection events (e.g., detection events 294). As discussed above, examples of such artifacts/log entries may include but are not limited to: IP addresses, file names, user names, host names, file hashes, port IDs, etc.

Accordingly and when identifying 2006 two or more associated detection events (e.g., detection events 294) included within the plurality of detection events (e.g., detection events 294), threat mitigation process 10 may identify 2010 two or more detection events (e.g., detection events 294) included within the plurality of detection events (e.g., detection events 294) that have common artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226).

Further and when grouping 2008 the two or more associated detection events (e.g., detection events 294) into a security incident (e.g., a group of related detection events), threat mitigation process 10 may group 2012 the one or more artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226) associated with each of the two or more associated detection events (e.g., detection events 294) to form an artifact/log entry set for the security incident (e.g., a group of related detection events), which are provided to one of more analysts (e.g., analyst 256) of threat mitigation process 10.

As would be expected and over time, threat mitigation process 10 may receive 2014 one or more additional detection events (e.g., one or more of detection events 294) concerning one or more additional security events occurring on the two or more security-relevant subsystem (e.g., security-relevant subsystems 226) within the computing platform (e.g., computing platform 60). Accordingly, threat mitigation process 10 may add 2016 the one or more additional detection events (e.g., detection events 294) to the security incident (e.g., the above-described group of related detection events) if the one or more additional detection events (e.g., one or more of detection events 294) are related to the two or more associated detection events (e.g., two or more of detection events 294).

PHASE 3: As discussed above, the detection events (e.g., detection events 294) are not detected via detection rules (e.g., detection rules 292) defined and executed on the pieces of technology (e.g., central devices and/or end point devices). Specifically, threat mitigation process 10 may be configured to directly detect such detection events (e.g., detection events 294) by executing queries on the pieces of technology (e.g., central devices and/or end point devices).

Specifically:

-   -   Threat mitigation process 10 may be configured to define a         service to generate detection events (e.g., detection events         294) directly via customer technology (e.g., a central device         and an end point device).     -   For example, threat mitigation process 10 may be configured to         define a rules language/engine that allows the definition of         rules (e.g., detection rules 292) that define how detection         events (e.g., detection events 294) may be triggered from         underlying data queries within the customer technology (e.g., a         central device and an end point device).     -   Each of these detection events (e.g., detection events 294) may         have one or more “artifacts” associated with them, wherein these         artifacts may include but are not limited to IP addresses, file         names, user name, host names, file hashes, etc.     -   Typically, detection events are defined by SEIMS (e.g., SIEM         system 230), which include correlation engines to correlate data         and make decisions concerning the same (e.g., whether a         detection event has occurred). Unfortunately, SIEMS are costly         to operate.     -   Fortunately and through the use of threat mitigation process 10         (which may effectuate correlation engine functionality) and a         datastore (e.g., a data lake), the functionality of a SEIM         (e.g., SIEM system 230) may be emulated . . . thus eliminating         the need for a SIEM.     -   Accordingly and in this phase, threat mitigation process 10 does         not rely on the underlying customer technology (e.g., a central         device and an end point device) to generate the detection events         (e.g., detection events 294). Instead, threat mitigation process         10 may directly execute queries on the underlying customer         technology (e.g., a central device and an end point device) to         self-generate the detection events (e.g., detection events 294).     -   Threat mitigation process 10 may be configured to allow this         service to be run on a schedule and e.g., analyst 256 may run         ad-hoc queries against the customer technologies (e.g., a         central device and an end point device). These queries may be         proactive or reactive (e.g., in response to a first step (or         steps) of known attack style),     -   Threat mitigation process 10 may be configured to enable a user         of threat mitigation process 10 to define a single search in a         universal language, wherein threat mitigation process 10 may         then translate this single search into a plurality of         technology-specific searches that are executable on the discrete         pieces of customer technology (e.g., server computers 200, 202,         desktop computer 204, laptop computer 206, network 208, web         application firewall 212, wireless access point 214, switch 216,         router 218, gateway 220, NAS 222, and API Gateway 224).     -   The data generated by these searches may be written in a common         data format and stored within a datastore (e.g., a data lake),         wherein the results of these searches may be analyzed by threat         mitigation process 10 to determine if these searches resulted in         new detection events.     -   The detection events (e.g., detection events 294) that are         occurring (in this example) on one or more hosts may be         generated via detection rules (e.g., detection rules 292) native         to (or defined by) these hosts or via detection rules (e.g.,         detection rules 292) defined by threat mitigation process 10.     -   As new detection events occur, threat mitigation process 10 may         process each new detection event to determine if the new         detection event is part of (i.e., associated with) a         previously-defined security incident. When making such a         determination, threat mitigation process 10 may utilize logical         rules and/or determine the amount of time that has passed since         the last detection event in the security incident.     -   In the event that a new detection event is associated with a         previously-defined security incident, threat mitigation process         10 may update the previously-defined security incident to         include the new detection event and any new artifacts associated         therewith, thus allowing for a more thorough and up-to-date         processing of the security event by e.g., analyst 256.

As will be discussed below in greater detail, threat mitigation process 10 may be configured to directly query the customer's technology (e.g., a central device or an end point device) so that the results of such queries may be received/processed by threat mitigation process 10 and/or analyst 256.

For example and referring also to FIG. 36 , threat mitigation process 10 may define 2100 a first query (e.g., a first query of plurality of queries 264) for a first security-relevant subsystem (e.g., a first subsystem of security-relevant subsystems 226) within a computing platform (e.g., computing platform 60), wherein threat mitigation process 10 may process 2102 the first query (e.g., a first query of plurality of queries 264) on the first security-relevant subsystem (e.g., a first subsystem of security-relevant subsystems 226) to generate a first data set (e.g., a first result set of plurality of result sets 266) concerning security events occurring on the first security-relevant subsystem (e.g., a first subsystem of security-relevant subsystems 226).

The format of this first data set (e.g., the first result set of plurality of result sets 266) may vary depending upon the manner in which threat mitigation process 10 is implemented. For example and in some implementations, this first data set (e.g., the first result set of plurality of result sets 266) may be raw data that is e.g., in the form of the raw result of the first query (e.g., the first query of plurality of queries 264). Further and in other implementations, this first data set (e.g., the first result set of plurality of result sets 266) may be processed data that is e.g., in the form of the plurality of detection events (e.g., detection events 294) that are the result of the first query (e.g., the first query of plurality of queries 264).

Threat mitigation process 10 may receive 2104 the first data set (e.g., the first result set of plurality of result sets 266) concerning the security events occurring on the first security-relevant subsystem (e.g., one of security-relevant subsystems 226); may identify 2106 two or more associated detection events (e.g., two or more of detection events 294) defined within the first data set (e.g., the first result set of plurality of result sets 266); and may group 2108 the two or more associated detection events (e.g., two or more of detection events 294) to define a security incident (e.g., a group of related detection events), which may be provided to one of more analysts (e.g., analyst 256) of threat mitigation process 10.

Additionally and as discussed above, one or more artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226) may be associated with each of the first data set (e.g., the first result set of plurality of result sets 266). As discussed above, examples of such artifacts/log entries may include but are not limited to: IP addresses, file names, user names, host names, file hashes, port IDs, etc.

Accordingly and when identifying 2106 two or more associated detection events (e.g., two or more of detection events 294) defined within the first data set (e.g., the first result set of plurality of result sets 266), threat mitigation process 10 may identify 2110 two or more detection events (e.g., two or more of detection events 294) defined within the first data set (e.g., the first result set of plurality of result sets 266) that have common artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226).

Further and when grouping 2108 the two or more associated detection events (e.g., two or more of detection events 294) to define a security incident (e.g., a group of related detection events), threat mitigation process 10 may group 2112 the one or more artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226) associated with each of the two or more associated detection events (e.g., two or more of detection events 294) to form an artifact/log entry set for the security incident (e.g., a group of related detection events), which may be provided to one of more analysts (e.g., analyst 256) of threat mitigation process 10.

Threat mitigation process 10 may define 2114 a second query (e.g., a second query of plurality of queries 264) for a second security-relevant subsystem (e.g., a second subsystem of security-relevant subsystems 226) within the computing platform (e.g., computing platform 60), wherein threat mitigation process 10 may process 2116 the second query (e.g., a second query of plurality of queries 264) on the second security-relevant subsystem (e.g., a second subsystem of security-relevant subsystems 226) to generate a second data set (e.g., a second result set of plurality of result sets 266) concerning security events occurring on the second security-relevant subsystem (e.g., a second subsystem of security-relevant subsystems 226).

The format of this second data set (e.g., a second result set of plurality of result sets 266) may vary depending upon the manner in which threat mitigation process 10 is implemented. For example and in some implementations, this second data set (e.g., the second result set of plurality of result sets 266) may be raw data that is e.g., in the form of the raw result of the second query (e.g., the second query of plurality of queries 264). Further and in other implementations, this second data set (e.g., the second result set of plurality of result sets 266) may be processed data that is e.g., in the form of the plurality of detection events (e.g., detection events 294) that are the result of the second query (e.g., the second query of plurality of queries 264).

Threat mitigation process 10 may receive 2118 the second data set (e.g., the second result set of plurality of result sets 266) concerning the security events occurring on the second security-relevant subsystem (e.g., one of security-relevant subsystems 226); may identify 2120 two or more associated detection events (e.g., two or more of detection events 294) defined within the second data set (e.g., the second result set of plurality of result sets 266); and may group 2122 the two or more associated detection events (e.g., two or more of detection events 294) to define a security incident (e.g., a group of related detection events), which may be provided to one of more analysts (e.g., analyst 256) of threat mitigation process 10.

Additionally and as discussed above, one or more artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226) may be associated with each of the second data set (e.g., the second result set of plurality of result sets 266). As discussed above, examples of such artifacts/log entries may include but are not limited to: IP addresses, file names, user names, host names, file hashes, port IDs, etc.

Accordingly and when identifying 2120 two or more associated detection events (e.g., two or more of detection events 294) defined within the second data set (e.g., the second result set of plurality of result sets 266), threat mitigation process 10 may identify 2124 two or more detection events (e.g., two or more of detection events 294) defined within the second data set (e.g., the second result set of plurality of result sets 266) that have common artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226).

Further and when grouping 2122 the two or more associated detection events (e.g., two or more of detection events 294) to define a security incident (e.g., a group of related detection events), threat mitigation process 10 may group 2126 the one or more artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226) associated with each of the two or more associated detection events (e.g., two or more of detection events 294) to form an artifact/log entry set for the security incident (e.g., a group of related detection events), which may be provided to one of more analysts (e.g., analyst 256) of threat mitigation process 10.

As discussed above, the plurality of security events may include one or more of: Denial of Service (DoS) events; Distributed Denial of Service DDoS events; Man-in-the-Middle (MitM) events; phishing events; Password Attack events; SQL Injection events; Cross-Site Scripting (XSS) events; Insider Threat events; spamming events; malware events; web attacks; and exploitation events.

As discussed above, examples of the security-relevant subsystem (e.g., security-relevant subsystems 226) may include one or more of: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems; Antivirus systems; operating systems; data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform (e.g., computing platform 60).

PHASE 4: As discussed above, threat mitigation process 10 may be configured to enable a user of threat mitigation process 10 to define a universal detection rule (e.g., universal detection rule 296) in a common language for e.g., computing platform 60. Threat mitigation process 10 may then translate this universal detection rule (e.g., universal detection rule 296) into a plurality of technology-specific detection rules (e.g., detection rules 292) that are executable on the discrete pieces of customer technology (e.g., server computers 200, 202, desktop computer 204, laptop computer 206, network 208, web application firewall 212, wireless access point 214, switch 216, router 218, gateway 220, NAS 222, and API Gateway 224).

Specifically:

-   -   Threat mitigation process 10 may be configured to define a         service that allows for the definition of detection rules (e.g.,         detection rules 292) to be managed within customer technologies         (e.g., server computers 200, 202, desktop computer 204, laptop         computer 206, network 208, web application firewall 212,         wireless access point 214, switch 216, router 218, gateway 220,         NAS 222, and API Gateway 224).     -   Threat mitigation process 10 may be configured to enable a user         of threat mitigation process 10 to define a detection rule in a         universal language, wherein threat mitigation process 10 may         then translate this single detection rule into a plurality of         technology-specific detection rules that are executable on the         discrete pieces of customer technology (e.g., server computers         200, 202, desktop computer 204, laptop computer 206, network         208, web application firewall 212, wireless access point 214,         switch 216, router 218, gateway 220, NAS 222, and API Gateway         224).     -   Accordingly, if a user is defining correlation rules for a SIEM,         these correlation rules may be made using a common language.         These common language correlation rules may then be translated         into e.g., Splunk or QRadar language correlation rules and then         automatically installed on these SIEMS.     -   Individual users may tune these detection rules (e.g., detection         rules 292) by adding e.g., allow lists and/or block lists for         specific artifacts including but not limited to log sources,         hostnames, users, IP addresses, etc.     -   Threat mitigation process 10 may be configured to tune these         detection rules (e.g., detection rules 292) using e.g.,         reference lists to raise or lower the importance and/or         criticality of these rules.

As will be discussed below in greater detail, threat mitigation process 10 may be configured to enable the definition of universal detection rules that may be translated into bespoke detection rules that are executable by the customer's technology (e.g., a central device or an end point device), wherein these bespoke rules are provided to the customer's technology for local execution thereon.

For example and referring also to FIG. 37 , threat mitigation process 10 may define 2200 a universal detection rule (e.g., universal rule 296) for execution on a computing platform (e.g., computing platform 60). These universal detection rules (e.g., universal rule 296) may be written in a common language that may be translated into a plurality of technology-specific rules (e.g., one or more of detection rules 292) that are executable on the discrete pieces of customer's technology.

Threat mitigation process 10 may process 2202 the universal detection rule (e.g., universal rule 296) to generate a first detection rule (e.g., a first rule of detection rules 292) that is executable on a first security-relevant subsystem (e.g., a first subsystem of security-relevant subsystems 226) within the computing platform (e.g., computing platform 60) and may provide 2204 the first detection rule (e.g., the a first rule of detection rules 292) to the first security-relevant subsystem (e.g., a first rule of security-relevant subsystems 226) for execution on the first security-relevant subsystem (e.g., a first rule of security-relevant subsystems 226).

Further, threat mitigation process 10 may process 2206 the universal detection rule (e.g., universal rule 296) to generate a second detection rule (e.g., a second rule of detection rules 292) that is executable on a second security-relevant subsystem (e.g., a second of security-relevant subsystems 226) within the computing platform (e.g., computing platform 60) and may provide 2208 the second detection rule (e.g., the second rule of detection rules 292) to the second security-relevant subsystem (e.g., the second of security-relevant subsystems 226) for execution on the second security-relevant subsystem (e.g., the second of security-relevant subsystems 226).

Threat mitigation process 10 may receive 2210 a first plurality of detection events (e.g., a first portion of detection events 294) from the first detection rule (e.g., a first rule of detection rules 292) executed on the first security-relevant subsystem (e.g., the first subsystem of security-relevant subsystems 226), wherein the first plurality of detection events (e.g., the first portion of detection events 294) concerns a plurality of security events occurring on the first security-relevant subsystem (e.g., a first subsystem of security-relevant subsystems 226).

Threat mitigation process 10 may identify 2212 two or more associated detection events (e.g., two or more of detection events 294) included within the first plurality of detection events (e.g., the first portion of detection events 294) and may group 2214 the two or more associated detection events (e.g., two or more of detection events 294) to define a security incident (e.g., a group of related detection events), which may be provided to one of more analysts (e.g., analyst 256) of threat mitigation process 10.

Additionally, one or more artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226) may be associated with each of first plurality of detection events (e.g., detection events 294). As discussed above, examples of such artifacts/log entries may include but are not limited to: IP addresses, file names, user names, host names, file hashes, port IDs, etc.

Accordingly and when identifying 2212 two or more associated detection events (e.g., two or more of detection events 294) included within the first plurality of detection events (e.g., detection events 294), threat mitigation process 10 may identify 2216 two or more detection events (e.g., two or more of detection events 294) included within the first plurality of detection events (e.g., detection events 294) that have common artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226).

Further and when grouping 2214 the two or more associated detection events (e.g., two or more of detection events 294) to define a security incident (e.g., a group of related detection events), threat mitigation process 10 may group 2218 the one or more artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226) associated with each of the two or more associated detection events (e.g., two or more of detection events 294) to form an artifact/log entry set for the security incident (e.g., a group of related detection events), which may be provided to one of more analysts (e.g., analyst 256) of threat mitigation process 10.

Threat mitigation process 10 may receive 2220 a second plurality of detection events (e.g., a second portion of detection events 294) from the second detection rule (e.g., a second rule of detection rules 292) executed on the second security-relevant subsystem (e.g., the second subsystem of security-relevant subsystems 226), wherein the second plurality of detection events (e.g., the second portion detection events 294) concerns a plurality of security events occurring on the second security-relevant subsystem (e.g., the second subsystem of security-relevant subsystems 226).

Threat mitigation process 10 may identify 2222 two or more associated detection events (e.g., two or more of detection events 294) included within the second plurality of detection events (e.g., the second portion of detection events 294) and may group 2224 the two or more associated detection events (e.g., two or more of detection events 294) to define a security incident (e.g., a group of related detection events), which may be provided to one of more analysts (e.g., analyst 256) of threat mitigation process 10.

Additionally, one or more artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226) may be associated with each of second plurality of detection events (e.g., the second portion of detection events 294). As discussed above, examples of such artifacts/log entries may include but are not limited to: IP addresses, file names, user names, host names, file hashes, port IDs, etc.

Accordingly and when identifying 2222 two or more associated detection events (e.g., two or more of detection events 294) included within the second plurality of detection events (e.g., the second portion of detection events 294), threat mitigation process 10 may identify 2226 two or more detection events (e.g., two or more of detection events 294) included within the second plurality of detection events (e.g., the second portion of detection events 294) that have common artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226), which may be provided to one of more analysts (e.g., analyst 256) of threat mitigation process 10.

Further and when grouping 2224 the two or more associated detection events (e.g., two or more of detection events 294) to define a security incident (e.g., a group of related detection events), threat mitigation process 10 may group 2228 the one or more artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226) associated with each of the two or more associated detection events (e.g., two or more of detection events 294) to form an artifact/log entry set for the security incident (e.g., a group of related detection events), which may be provided to one of more analysts (e.g., analyst 256) of threat mitigation process 10.

As discussed above, the plurality of security events may include one or more of: Denial of Service (DoS) events; Distributed Denial of Service DDoS events; Man-in-the-Middle (MitM) events; phishing events; Password Attack events; SQL Injection events; Cross-Site Scripting (XSS) events; Insider Threat events; spamming events; malware events; web attacks; and exploitation events.

As discussed above, examples of the first security-relevant subsystem (e.g., a first of security-relevant subsystems 226) and/or the second security-relevant subsystem (e.g., a second of security-relevant subsystems 226) may include one or more of: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems; Antivirus systems; operating systems; data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform (e.g., computing platform 60).

PHASE 5: As discussed above, threat mitigation process 10 may be configured to utilize machine learning/artificial intelligence to analyze e.g., current detection rules (e.g., detection rules 292) and historical data concerning previously-detected security events (e.g., DDoS events, DoS events, phishing events, spamming events, malware events, web attacks, and exploitation events) so that new detection rules may be automatically generated and/or executed by threat mitigation process 10). Accordingly and in such a configuration, security events (e.g., DDoS events, DoS events, phishing events, spamming events, malware events, web attacks, and exploitation events) may be automatically detected and detection rules (e.g., detection rules 292) may be automatically generated based upon these automatically detected security events.

Specifically:

-   -   Threat mitigation process 10 may be configured to leverage         machine learning and/or artificial intelligence to process data         generated via one or more of the above-described phases to         generate more advanced detection rules. For example, if threat         mitigation process 10 uses ML/AI to determine that a data set is         indicative of a detection event, threat mitigation process 10         may generate a detection event definition based upon this data         set, wherein this detection event definition may be used to         identify future detection events.     -   Accordingly, threat mitigation process 10 may be configured to         detect emerging threats without needing rules specifically         written for such threats. Specifically, threat mitigation         process 10 may utilize data generated via one or more of the         above-described phases to generate more advanced detection         rules.     -   For example, assume that Host A repeatedly does a suspicious         port scan. But whenever such a scanning operation is         investigated, threat mitigation process 10 determines that it is         nothing (i.e., a harmless event necessitated by the particular         type of work that Host A performs). Accordingly, threat         mitigation process 10 may decrease the level of sensitivity         applied to this particular type of scan on this particular host.     -   Conversely, if it is determined that Host B often falls victim         to cyberattacks (due to their outward exposure within computing         platform 60), threat mitigation process 10 may increase the         level of sensitivity applied to activities performed by this         particular host. Therefore and for Host B, threat mitigation         process 10 may determine that an event that would typically be         deemed non-concerning on other hosts may be deemed concerning on         Host B.

As will be discussed below in greater detail, threat mitigation process 10 may build a event repository from a plurality of detection events (e.g., detection events 294) and utilize machine learning to review the event repository to extract attack patterns so that future attacks may be thwarted.

For example and referring also to FIG. 38 , threat mitigation process 10 may receive 2300 a plurality of detection events (e.g., detection events 294) concerning a plurality of security events occurring on multiple security-relevant subsystem (e.g., security-relevant subsystems 226) within one or more computing platforms (e.g., computing platform 60).

As discussed above, the plurality of security events may include one or more of: Denial of Service (DoS) events; Distributed Denial of Service DDoS events; Man-in-the-Middle (MitM) events; phishing events; Password Attack events; SQL Injection events; Cross-Site Scripting (XSS) events; Insider Threat events; spamming events; malware events; web attacks; and exploitation events.

As discussed above, examples of the security-relevant subsystems (e.g., a first of security-relevant subsystems 226) may include one or more of: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems; Antivirus systems; operating systems; data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform (e.g., computing platform 60).

Threat mitigation process 10 may store 2302 the plurality of detection events (e.g., detection events 294) to form an event repository (e.g., event repository 298). Examples of the event repository (e.g., event repository 298) may include but are not limited to a database, a datastore, a data lake, a storage location, a storage folder, a hard drive, and a solid-state storage device.

Threat mitigation process 10 may process 2304 the event repository (e.g., event repository 298) using a machine learning model (e.g., probabilistic process 56) to identify attack patterns defined within the plurality of detection events (e.g., detection events 294) stored within the event repository (e.g., event repository 298), thus defining one or more identified attack patterns (e.g., identified attack patterns 299).

As discussed above and with respect to artificial intelligence/machine learning being utilized to process data sets, an initial probabilistic model may be defined, wherein this initial probabilistic model may be subsequently (e.g., iteratively or continuously) modified and revised, thus allowing the probabilistic models and the artificial intelligence systems (e.g., probabilistic process 56) to “learn” so that future probabilistic models may be more precise and may explain more complex data sets. As further discussed above, probabilistic process 56 may define an initial probabilistic model for accomplishing a defined task (e.g., the analyzing of information 58), wherein the probabilistic model may be utilized to go from initial observations about information 58 (e.g., as represented by the initial branches of a probabilistic model) to conclusions about information 58 (e.g., as represented by the leaves of a probabilistic model). Accordingly and through the use of probabilistic process 56, massive data sets concerning security events may be processed so that a probabilistic model may be defined (and subsequently revised) to assign a threat level to the above-described security event.

Threat mitigation process 10 may be configured to gather the detection events (e.g., detection events 294) from a plurality of computing platforms, thus providing a more diverse composition of the detection events (e.g., detection events 294). For example, the one or more computing platforms (e.g., computing platform 60) may include: a first computing platform (e.g., a first example of computing platform 60) of a first client (e.g., a first client's computing platform); and at least a second computer platform (e.g., a second example of computing platform 60) of at least a second client (e.g., a second client's computing platform).

As discussed above, one or more artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226) may be associated with each of the plurality of detection events (e.g., detection events 294), wherein examples of such artifacts/log entries may include but are not limited to: IP addresses, file names, user names, host names, file hashes, port IDs, etc.

Accordingly and when processing 2304 the event repository (e.g., event repository 298) using a machine learning model (e.g., probabilistic process 56) to identify attack patterns (e.g., identified attack patterns 299) defined within the plurality of detection events (e.g., detection events 294) stored within the event repository (e.g., event repository 298), threat mitigation process 10 may process 2306 the event repository (e.g., event repository 298) using a machine learning model (e.g., probabilistic process 56) to identify attack patterns (e.g., identified attack patterns 299) defined within the plurality of detection events (e.g., detection events 294) and their associated artifacts (e.g., artifacts 250)/log entries (e.g., within a log file maintained by SIEM system 230 and/or security-relevant subsystems 226) stored within the event repository (e.g., event repository 298).

Additionally, threat mitigation process 10 may solicit 2308 human feedback concerning the one or more identified attack patterns (e.g., identified attack patterns 299) and may utilize 2310 the human feedback to train the machine learning model (e.g., probabilistic process 56). For example, and when threat mitigation process 10 identifies an attack pattern (e.g., identified attack patterns 299), threat mitigation process 10 may provide the identified attack pattern (e.g., identified attack patterns 299) to one of more analysts (e.g., analyst 256) of threat mitigation process 10 to solicit 2308 human feedback concerning the same and may utilize 2310 such human feedback from the one of more analysts (e.g., analyst 256) to train the machine learning model (e.g., probabilistic process 56).

As is known in the art, machine learning model training involves the process of feeding a machine learning algorithm (e.g., probabilistic process 56) with a dataset (e.g., event repository 298) in order to teach it how to make predictions or decisions based on that data (e.g., event repository 298). This process is usually performed by dividing the data (e.g., event repository 298) into two or more sets, where one set is used for training the model (e.g., probabilistic process 56) and the other set is used for evaluating the performance of the trained model.

The general steps for machine learning model training are as follows:

-   -   Data Preparation: The data is collected and prepared for use in         training the model. This may involve cleaning and preprocessing         the data, as well as splitting it into training and evaluation         sets.     -   Model Selection: A suitable machine learning algorithm is chosen         for the task at hand. This may involve selecting from a range of         algorithms, such as decision trees, support vector machines, or         neural networks.     -   Training the Model: The chosen algorithm is trained on the         training data, adjusting the model's parameters to minimize the         difference between its predictions and the actual outcomes.     -   Evaluating the Model: The trained model is then evaluated using         the evaluation dataset to determine how well it generalizes to         new, unseen data. The performance of the model is assessed using         metrics such as accuracy, precision, recall, or F1 score.     -   Fine-tuning the Model: If the performance of the model is not         satisfactory, the parameters of the model may be adjusted, or         the model architecture may be modified, in order to improve its         performance.     -   Deployment: Once the model has been trained and evaluated, it         can be deployed to make predictions on new data.

Overall, the process of machine learning model training is iterative and involves continuous refinement of the model until it meets the desired performance criteria.

Additionally, threat mitigation process 10 may define 2312 a new detection rule (e.g., a new universal rule 296 and/or a new technology-specific detection rules 292) based, at least in part, upon the one or more identified attack patterns (e.g., identified attack patterns 299). For example, threat mitigation process 10 may analyze the identified attack patterns (e.g., identified attack patterns 299) to “learn” the way that such attacks occur and may define 2312 a new detection rule (e.g., a new universal rule 296 and/or a new technology-specific detection rule 292) based upon such analysis.

Further, threat mitigation process 10 may modify 2314 an existing detection rule (e.g., an existing universal rule 296 and/or an existing technology-specific detection rule 292) based, at least in part, upon the one or more identified attack patterns (e.g., identified attack patterns 299). For example, threat mitigation process 10 may analyze the identified attack patterns (e.g., identified attack patterns 299) to “learn” the way that such attacks occur and may modify 2314 an existing detection rule (e.g., an existing universal rule 296 and/or an existing technology-specific detection rule 292) based upon such analysis.

Additionally, threat mitigation process 10 may initiate 2316 an investigation of current activity within the one or more computing platforms (e.g., computing platform 60) based, at least in part, upon the current activity being similar to the one or more identified attack patterns (e.g., identified attack patterns 299). For example, threat mitigation process 10 may analyze the identified attack patterns (e.g., identified attack patterns 299) to see if platform activity is following a path defined within an identified attack pattern (e.g., identified attack patterns 299). Accordingly, if an identified attack pattern (e.g., identified attack patterns 299) follows a path of Step A

Step B

Step C

Step D

Step E

Step F and threat mitigation process 10 notices platform activity of Step A

Step B

Step C

Step D, threat mitigation process 10 may initiate 2316 an investigation of current activity within the one or more computing platforms (e.g., computing platform 60) to determine if Step E

Step F are in process.

PHASE 6: As discussed above, threat mitigation process 10 may be configured to store data concerning computing platform 60, the customer technology contained therein (e.g., server computers 200, 202, desktop computer 204, laptop computer 206, network 208, web application firewall 212, wireless access point 214, switch 216, router 218, gateway 220, NAS 222, and API Gateway 224), and the security events occurring therein (e.g., DDoS events, DoS events, phishing events, spamming events, malware events, web attacks, and exploitation events). Threat mitigation process 10 may further be configured to present such data in a fashion that identifies relationships between the entities within the data, as opposed to the data associated with the entities themselves.

Specifically:

-   -   Threat mitigation process 10 may be configured to present data         obtained from the customer technology (e.g., server computers         200, 202, desktop computer 204, laptop computer 206, network         208, web application firewall 212, wireless access point 214,         switch 216, router 218, gateway 220, NAS 222, and API Gateway         224) in a fashion that identifies relationships between the         entities within the data. So instead of expressing a query based         upon the entities within the stored data, the query may be based         upon the relationships between the entities within the stored         data.     -   For example, threat mitigation process 10 may be configured to         store the obtained data within a graph database that allows         detection rule logic to be built using graph style queries in         e.g., the “cypher” query language, the “GSQ” (Graph query)         language, or a similar language, thus allowing detection rules         to be constructed that leverage the relationships between         disparate detection events.     -   In computing, a graph database is a database that uses graph         structures for semantic queries with nodes, edges, and         properties to represent and store data. A key concept of the         system is the graph (or edge or relationship), wherein the graph         relates the data items in the datastore to a collection of nodes         and edges (the edges representing the relationships between the         nodes). These relationships allow data in the datastore to be         linked together directly and, in many cases, retrieved with one         operation. Graph databases may hold the relationships between         data as a priority. Accordingly, querying relationships may be         efficiently identified, as they are perpetually stored in the         database. These relationships may be intuitively visualized         using graph databases, making them useful for heavily         inter-connected data.

As will be discussed below in greater detail, threat mitigation process 10 may build an event repository from a plurality of detection events (e.g., detection events 294), wherein the content of this event repository may be compatible/searchable with a graph database.

For example and referring also to FIG. 39 , threat mitigation process 10 may receive 2400 a plurality of detection events (e.g., detection events 294) concerning a plurality of security events occurring on multiple security-relevant subsystems (e.g., security-relevant subsystems 226) within one or more computing platforms (e.g., computing platform 60).

As discussed above, the plurality of security events may include one or more of: Denial of Service (DoS) events; Distributed Denial of Service DDoS events; Man-in-the-Middle (MitM) events; phishing events; Password Attack events; SQL Injection events; Cross-Site Scripting (XSS) events; Insider Threat events; spamming events; malware events; web attacks; and exploitation events.

As discussed above, examples of the security-relevant subsystem (e.g., security-relevant subsystems 226) may include one or more of: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems; Antivirus systems; operating systems; data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform (e.g., computing platform 60).

Threat mitigation process 10 may process 2402 the plurality of detection events (e.g., detection events 294) to make them compatible with a graph database (e.g., graph database 297), thus defining processed detection events (e.g., detection events 294).

As is known in the art, a graph database (e.g., graph database 297) is a type of database that stores and manages data using a graph data model. In a graph database, data is represented as nodes (also known as vertices) and edges (also known as relationships or links) between those nodes. Each node represents an entity or object, and each edge represents a relationship between two nodes. For example, in a social network graph database, a person would be represented as a node and their connection with other people (such as friends, family members, or colleagues) would be represented as edges between the nodes. Graph databases are particularly useful for managing complex and interconnected data, such as social networks, recommendation engines, or fraud detection systems. Graph databases enable efficient querying and analysis of relationships and patterns in the data, as well as the ability to make real-time recommendations or predictions based on that data. Some popular graph databases include Neo4j, Amazon Neptune, and Microsoft Azure Cosmos DB.

Graph databases (e.g., graph database 297) offer several benefits over traditional databases, including:

-   -   Ability to model complex relationships: Graph databases are         specifically designed to handle complex relationships between         data points. They can store and analyze data in a more natural         way, without the need for complex joins or complex schema design         that traditional databases require.     -   Flexibility: Graph databases are schema-free, meaning you can         add or change the structure of the data model on-the-fly without         having to make any changes to the underlying database schema.         This flexibility makes it easier to adapt to changing business         needs and data requirements.     -   Performance: Graph databases excel at queries involving complex         relationships and patterns, which can be time-consuming and         inefficient to execute in traditional databases. Graph databases         use optimized indexing and traversal algorithms to quickly         access and analyze data.     -   Scalability: Graph databases can scale horizontally across         multiple machines, enabling them to handle large and growing         datasets with ease.     -   Faster development and deployment: Graph databases can reduce         the time and effort needed to develop and deploy applications.         Developers can work more quickly because they don't have to deal         with the complexities of data normalization and schema design         that are required in traditional databases.

Overall, graph databases (e.g., graph database 297) provide a powerful and flexible way to manage complex relationships and enable faster, more efficient querying and analysis of data.

Threat mitigation process 10 may store 2404 the processed detection events (e.g., detection events 294) to generate a graph content repository (e.g., event repository 298).

When processing 2402 the plurality of detection events (e.g., detection events 294) to make them compatible with a graph database (e.g., graph database 297), thus defining processed detection events (e.g., detection events 294), threat mitigation process 10 may identify 2406 nodes and edges within the plurality of detection events (e.g., detection events 294) to make them compatible with the graph database (e.g., graph database 297).

Typically, data needs to be processed to make it usable within a graph database (e.g., graph database 297). This is because graph databases require data to be represented in a specific format, with nodes representing entities and edges representing relationships between those entities. The process of preparing data for a graph database involves identifying the entities in your data, defining the relationships between those entities, and creating a graph structure that represents those entities and relationships.

This process can involve a range of data processing techniques, including data cleaning, data transformation, and data modeling. Some graph databases also provide tools and features to help automate this process, such as automatic schema inference, data import/export utilities, and graph visualization tools.

As discussed above, threat mitigation process 10 may be configured to gather the detection events (e.g., detection events 294) from a plurality of computing platforms, thus providing a more diverse composition of the detection events (e.g., detection events 294). For example, the one or more computing platforms (e.g., computing platform 60) may include: a first computing platform (e.g., a first example of computing platform 60) of a first client (e.g., a first client's computing platform); and at least a second computer platform (e.g., a second example of computing platform 60) of at least a second client (e.g., a second client's computing platform).

Threat mitigation process 10 may process 2408 the graph content repository (e.g., event repository 298) using a machine learning model (e.g., probabilistic process 56) to identify attack patterns (e.g., identified attack patterns 299) defined within the processed detection events (e.g., detection events 294) stored within the graph content repository (e.g., event repository 298), thus defining one or more identified attack patterns (e.g., identified attack patterns 299).

As discussed above and with respect to artificial intelligence/machine learning being utilized to process data sets, an initial probabilistic model may be defined, wherein this initial probabilistic model may be subsequently (e.g., iteratively or continuously) modified and revised, thus allowing the probabilistic models and the artificial intelligence systems (e.g., probabilistic process 56) to “learn” so that future probabilistic models may be more precise and may explain more complex data sets. As further discussed above, probabilistic process 56 may define an initial probabilistic model for accomplishing a defined task (e.g., the analyzing of information 58), wherein the probabilistic model may be utilized to go from initial observations about information 58 (e.g., as represented by the initial branches of a probabilistic model) to conclusions about information 58 (e.g., as represented by the leaves of a probabilistic model). Accordingly and through the use of probabilistic process 56, massive data sets concerning security events may be processed so that a probabilistic model may be defined (and subsequently revised) to assign a threat level to the above-described security event.

Threat mitigation process 10 may solicit 2410 human feedback concerning the one or more identified attack patterns (e.g., identified attack patterns 299) and may utilize 2412 the human feedback to train the machine learning model (e.g., probabilistic process 56). As discussed above and when threat mitigation process 10 identifies an attack pattern (e.g., identified attack patterns 299), threat mitigation process 10 may provide the identified attack pattern (e.g., identified attack patterns 299) to one of more analysts (e.g., analyst 256) of threat mitigation process 10 to solicit 2410 human feedback concerning the same and may utilize 3412 such human feedback from the one of more analysts (e.g., analyst 256) to train the machine learning model (e.g., probabilistic process 56).

Additionally, threat mitigation process 10 may define 2414 a new detection rule (e.g., a new universal rule 296 and/or a new technology-specific detection rules 292) based, at least in part, upon the one or more identified attack patterns (e.g., identified attack patterns 299). For example, threat mitigation process 10 may analyze the identified attack patterns (e.g., identified attack patterns 299) to “learn” the way that such attacks occur and may define 2414 a new detection rule (e.g., a new universal rule 296 and/or a new technology-specific detection rules 292) based upon such analysis.

Further, threat mitigation process 10 may modify 2416 an existing detection rule (e.g., an existing universal rule 296 and/or an existing technology-specific detection rule 292) based, at least in part, upon the one or more identified attack patterns (e.g., identified attack patterns 299). For example, threat mitigation process 10 may analyze the identified attack patterns (e.g., identified attack patterns 299) to “learn” the way that such attacks occur and may modify 2416 an existing detection rule (e.g., an existing universal rule 296 and/or an existing technology-specific detection rule 292) based upon such analysis.

Additionally, threat mitigation process 10 may initiate 2418 an investigation of current activity within the one or more computing platforms (e.g., computing platform 60) based, at least in part, upon the current activity being similar to the one or more identified attack patterns (e.g., identified attack patterns 299). As discussed above, threat mitigation process 10 may analyze the identified attack patterns (e.g., identified attack patterns 299) to see if platform activity is following a path defined within an identified attack pattern (e.g., identified attack patterns 299). Accordingly, if an identified attack pattern (e.g., identified attack patterns 299) follows a path Step A

Step B

Step C

Step D

Step E

Step F and threat mitigation process 10 notices platform activity of Step A

Step B

Step C

Step D, threat mitigation process 10 may initiate 2418 an investigation of current activity within the one or more computing platforms (e.g., computing platform 60) to determine if Step E

Step F are in process.

General

As will be appreciated by one skilled in the art, the present disclosure may be embodied as a method, a system, or a computer program product. Accordingly, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, the present disclosure may take the form of a computer program product on a computer-usable storage medium having computer-usable program code embodied in the medium.

Any suitable computer usable or computer readable medium may be utilized. The computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non-exhaustive list) of the computer-readable medium may include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a transmission media such as those supporting the Internet or an intranet, or a magnetic storage device. The computer-usable or computer-readable medium may also be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer-usable medium may include a propagated data signal with the computer-usable program code embodied therewith, either in baseband or as part of a carrier wave. The computer usable program code may be transmitted using any appropriate medium, including but not limited to the Internet, wireline, optical fiber cable, RF, etc.

Computer program code for carrying out operations of the present disclosure may be written in an object-oriented programming language such as Java, Smalltalk, C++ or the like. However, the computer program code for carrying out operations of the present disclosure may also be written in conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through a local area network/a wide area network/the Internet (e.g., network 14).

The present disclosure is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, may be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general-purpose computer/special purpose computer/other programmable data processing apparatus, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that may direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowcharts and block diagrams in the figures may illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, may be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the disclosure in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the disclosure. The embodiment was chosen and described in order to best explain the principles of the disclosure and the practical application, and to enable others of ordinary skill in the art to understand the disclosure for various embodiments with various modifications as are suited to the particular use contemplated.

A number of implementations have been described. Having thus described the disclosure of the present application in detail and by reference to embodiments thereof, it will be apparent that modifications and variations are possible without departing from the scope of the disclosure defined in the appended claims. 

What is claimed is:
 1. A computer-implemented method, executed on a computing device, comprising: defining a universal detection rule for execution on a computing platform; processing the universal detection rule to generate a first detection rule that is executable on a first security-relevant subsystem within the computing platform; providing the first detection rule to the first security-relevant subsystem for execution on the first security-relevant subsystem; processing the universal detection rule to generate a second detection rule that is executable on a second security-relevant subsystem within the computing platform; and providing the second detection rule to the second security-relevant subsystem for execution on the second security-relevant subsystem.
 2. The computer-implemented method of claim 1 further comprising: receiving a first plurality of detection events from the first detection rule executed on the first security-relevant subsystem, wherein the first plurality of detection events concerns a plurality of security events occurring on the first security-relevant subsystem.
 3. The computer-implemented method of claim 2 further comprising: identifying two or more associated detection events included within the first plurality of detection events; and grouping the two or more associated detection events to define a security incident.
 4. The computer-implemented method of claim 3 wherein one or more artifacts/log entries are associated with each of first plurality of detection events.
 5. The computer-implemented method of claim 4 wherein: identifying two or more associated detection events included within the first plurality of detection events includes: identifying two or more detection events included within the first plurality of detection events that have common artifacts/log entries; and grouping the two or more associated detection events to define a security incident includes: grouping the one or more artifacts/log entries associated with each of the two or more associated detection events to form an artifact/log entry set for the security incident.
 6. The computer-implemented method of claim 1 further comprising: receiving a second plurality of detection events from the second detection rule executed on the second security-relevant subsystem, wherein the second plurality of detection events concerns a plurality of security events occurring on the second security-relevant subsystem.
 7. The computer-implemented method of claim 6 further comprising: identifying two or more associated detection events included within the second plurality of detection events; and grouping the two or more associated detection events to define a security incident.
 8. The computer-implemented method of claim 7 wherein one or more artifacts/log entries are associated with each of second plurality of detection events.
 9. The computer-implemented method of claim 8 wherein: identifying two or more associated detection events included within the second plurality of detection events includes: identifying two or more detection events included within the second plurality of detection events that have common artifacts/log entries; and grouping the two or more associated detection events to define a security incident includes: grouping the one or more artifacts/log entries associated with each of the two or more associated detection events to form an artifact/log entry set for the security incident.
 10. The computer-implemented method of claim 1 wherein the first security-relevant subsystem and/or the second security-relevant subsystem includes one or more of: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems; Antivirus systems; operating systems; data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform.
 11. A computer program product residing on a computer readable medium having a plurality of instructions stored thereon which, when executed by a processor, cause the processor to perform operations comprising: defining a universal detection rule for execution on a computing platform; processing the universal detection rule to generate a first detection rule that is executable on a first security-relevant subsystem within the computing platform; providing the first detection rule to the first security-relevant subsystem for execution on the first security-relevant subsystem; processing the universal detection rule to generate a second detection rule that is executable on a second security-relevant subsystem within the computing platform; and providing the second detection rule to the second security-relevant subsystem for execution on the second security-relevant subsystem.
 12. The computer program product of claim 11 further comprising: receiving a first plurality of detection events from the first detection rule executed on the first security-relevant subsystem, wherein the first plurality of detection events concerns a plurality of security events occurring on the first security-relevant subsystem.
 13. The computer program product of claim 12 further comprising: identifying two or more associated detection events included within the first plurality of detection events; and grouping the two or more associated detection events to define a security incident.
 14. The computer program product of claim 13 wherein one or more artifacts/log entries are associated with each of first plurality of detection events.
 15. The computer program product of claim 14 wherein: identifying two or more associated detection events included within the first plurality of detection events includes: identifying two or more detection events included within the first plurality of detection events that have common artifacts/log entries; and grouping the two or more associated detection events to define a security incident includes: grouping the one or more artifacts/log entries associated with each of the two or more associated detection events to form an artifact/log entry set for the security incident.
 16. The computer program product of claim 11 further comprising: receiving a second plurality of detection events from the second detection rule executed on the second security-relevant subsystem, wherein the second plurality of detection events concerns a plurality of security events occurring on the second security-relevant subsystem.
 17. The computer program product of claim 16 further comprising: identifying two or more associated detection events included within the second plurality of detection events; and grouping the two or more associated detection events to define a security incident.
 18. The computer program product of claim 17 wherein one or more artifacts/log entries are associated with each of second plurality of detection events.
 19. The computer program product of claim 18 wherein: identifying two or more associated detection events included within the second plurality of detection events includes: identifying two or more detection events included within the second plurality of detection events that have common artifacts/log entries; and grouping the two or more associated detection events to define a security incident includes: grouping the one or more artifacts/log entries associated with each of the two or more associated detection events to form an artifact/log entry set for the security incident.
 20. The computer program product of claim 11 wherein the first security-relevant subsystem and/or the second security-relevant subsystem includes one or more of: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems; Antivirus systems; operating systems; data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform.
 21. A computing system including a processor and memory configured to perform operations comprising: defining a universal detection rule for execution on a computing platform; processing the universal detection rule to generate a first detection rule that is executable on a first security-relevant subsystem within the computing platform; providing the first detection rule to the first security-relevant subsystem for execution on the first security-relevant subsystem; processing the universal detection rule to generate a second detection rule that is executable on a second security-relevant subsystem within the computing platform; and providing the second detection rule to the second security-relevant subsystem for execution on the second security-relevant subsystem.
 22. The computing system of claim 21 further comprising: receiving a first plurality of detection events from the first detection rule executed on the first security-relevant subsystem, wherein the first plurality of detection events concerns a plurality of security events occurring on the first security-relevant subsystem.
 23. The computing system of claim 22 further comprising: identifying two or more associated detection events included within the first plurality of detection events; and grouping the two or more associated detection events to define a security incident.
 24. The computing system of claim 23 wherein one or more artifacts/log entries are associated with each of first plurality of detection events.
 25. The computing system of claim 24 wherein: identifying two or more associated detection events included within the first plurality of detection events includes: identifying two or more detection events included within the first plurality of detection events that have common artifacts/log entries; and grouping the two or more associated detection events to define a security incident includes: grouping the one or more artifacts/log entries associated with each of the two or more associated detection events to form an artifact/log entry set for the security incident.
 26. The computing system of claim 21 further comprising: receiving a second plurality of detection events from the second detection rule executed on the second security-relevant subsystem, wherein the second plurality of detection events concerns a plurality of security events occurring on the second security-relevant subsystem.
 27. The computing system of claim 26 further comprising: identifying two or more associated detection events included within the second plurality of detection events; and grouping the two or more associated detection events to define a security incident.
 28. The computing system of claim 27 wherein one or more artifacts/log entries are associated with each of second plurality of detection events.
 29. The computing system of claim 28 wherein: identifying two or more associated detection events included within the second plurality of detection events includes: identifying two or more detection events included within the second plurality of detection events that have common artifacts/log entries; and grouping the two or more associated detection events to define a security incident includes: grouping the one or more artifacts/log entries associated with each of the two or more associated detection events to form an artifact/log entry set for the security incident.
 30. The computing system of claim 21 wherein the first security-relevant subsystem and/or the second security-relevant subsystem includes one or more of: CDN (i.e., Content Delivery Network) systems; DAM (i.e., Database Activity Monitoring) systems; UBA (i.e., User Behavior Analytics) systems; MDM (i.e., Mobile Device Management) systems; IAM (i.e., Identity and Access Management) systems; DNS (i.e., Domain Name Server) systems; Antivirus systems; operating systems; data lakes; data logs; security-relevant software applications; security-relevant hardware systems; and resources external to the computing platform. 